Re: help wanted, trying out a few ideas for post 0.94
From: Alan Horkan <horkana maths tcd ie>
To: discussions about usage and development of dia <dia-list gnome org>
Subject: Re: help wanted, trying out a few ideas for post 0.94
Date: Sun, 18 Jul 2004 01:46:28 +0100 (BST)
On Sat, 17 Jul 2004, Lars Clausen wrote:
> Date: Sat, 17 Jul 2004 09:02:58 +0200
> From: Lars Clausen <lars raeder dk>
> Reply-To: discussions about usage and development of dia
> <dia-list gnome org>
> To: discussions about usage and development of dia <dia-list gnome org>
> Subject: Re: help wanted, trying out a few ideas for post 0.94
> On Fri, 2004-07-16 at 01:00, Alan Horkan wrote:
> > since Dia compiled so nicely I've been trying out a few ideas
> > some of which are simple and others that I haven't got working yet but I
> > would appreciate help with (help, advice towards figuring it out myself
> > as much as possible)
> > http://www.maths.tcd.ie/~horkana/dia/menus.c
> > I'll provide proper patches later when I've got the ideas sorted out
> > the gist of it is, more keybindings , some renaming  and more menu
> > items to take advantage of the features of Dia I have only recently begun
> > to appreciate .
> >  I wanted to add keybindings using some of the Function keys (F8, F9)
> > but the keybindings for the toolbox seem to be in a differnt context to
> > the bindings in the document window, so if the toolbox is out of focus
> > they are not much use.
> > This fits in with an idea I have that I would like to make the File and
> > Help menus in the Toolbox and the Document Window more consistant with
> > each other. I mentioned yesterday that I was hoping to have the recent
> > files in both File menus, and although it could be be made optional I'd
> > prefer to always put them in a submenu 'Open Recent' (like the Gimp
> > does) and keep the file menu uncluttered. I haven't tried doing this yet
> > but I hope it will be easy enough (dont laugh if it is trivial, these
> > things are always easy in hindsight when you know how).
> > Going against consistancy but following the Gnome Guidelines I added
> > Preferences to the bottom of the edit menu and it feels comfortable (and
> > i used the letter E as the mnemonic so that you can go Alt,E,E to quickly
> > access the preferences even though the Gnome HIG has been misleading
> > people to do it differently).
> So you go against consistency to follow the HIG,
> then immediately stop following the HIG?
I'm confused! :P
No I'm really not.
I just happen to think the HIG is wrong on that one, it really bugs me.
I guess I had better reopen the bug I filed on it (it was closed but not
for any great reason and I want a second opinion)
I do generally agree with the HIG because I can understand their
reasoning most of the time and when I can see that there was a specific
logic but more people use Mozilla than just about any other Graphical
application and doing things unnecessarily differntly is a bad idea.
The HIG doesn't specifically say you should use this mnemonic it only
implies it from the screenshot
Mnemonics are not always best decided by a simple next letter algorithm,
which is what the HIG suggests. It is sometimes better to go a little
further and analyse what other items are using which mnemonics and to
consider using the start letter of the next word or syllable rather
than just the next letter.
For example sensible mnemonics for Redo would be _Redo or Re_do.
Gedit 2.2 happily ignores the screenshot and uses Pr_efrences.
It is just a faster more efficient bindings,
Alt+E+E gets you the Preferences dialog, quick and easily.
It is unlikely that there are many out there as pedantic as me, pedantic
enough to argue this minute point but once i started i couldn't drop the
matter and now I cant get the monkey off my back!
> Seems to match what many other programs do. Plural is only for menus
> like Tools where the plural refers to the items in the menu, not to
> things being operated on by the menu functions. Please make sure that
> all relevant files are updated.
I built and test it so it shouldn't be a problem.
> > Layers a lot with the Gimp, I wrote scripts to provide New Layer from
> > Cut/Copy that I'm rather proud of which make it very quick and easy to
> > create a new layer. Also Inkscape is working towards
> > adding Layers like functionality and I took a closer look at Adobe
> > Illustrator.
> Nifty, aren't they?
I also need to take a look at getting changing the label, having numbers
on the layer names would be nice (but no # or  or other junk). Also
'New' just takes up space, a New Layer ceases to be New as soon as you
have created it.
Not difficult, just something I've wanted for a while.
> > I think more people would appreciate the Layers features if they had
> > menu items, making them more discoverable and allow them to have
> > convenient keybindings. "money for old rope".
> The menu bar is getting awfully wide already.
I'll double check but I think the menubar is still narrow enough to fit on
small crappy displays, and as someone who long suffered it is something I
try to be careful about.
"Input Methods" is a two word menu item and when you have the menu bar on
the items in it still disappear. I was hoping that it would be going away
> Though it could go under Diagram.
I put it there at first, if it only contains an item or two that would
make sense but if I can get 5 or six layer items having its own menu would
> Or are you suggesting a context menu in the Layers dialog?
No, I think that a context menu in the Layers dialog would be a hideous
abomination. It would be undiscoverable (to all but those who randomly
right click all over the place, have read the documentation in great
detail, or have used another application that has implemented such
I dont particularly like having a Layers dialog/palette open on screen, I
prefer to work with it as a transative dialog. Providing a convenient top
level menu for Layer items makes it much less necessary to keep a Layer
palette onscreen taking up space if you really dont want it there.
The context menu in the Layers palette (as discussed previously more of a
right-click menu than an actual 'context' menu) in some other programs
particularly annoys me because it contains features not available from the
main menus (but it likely that will be corrected with the next menu
> > however I'm pretty clueless about how to get started on implenting the
> > hooks and callbacks to the existing functionality.
> Do what I do, look at what's there and figure it out. You'll need to
> add a menu item in app/menus.c, initialize those that can be ghosted in
> menus_initialize_updatable_items (adding appropriate struct entries in
> app/menus.h), add sensitivity updates in app/diagram.c, and add callback
> functions in app/commands.c.
thanks that is probably the imporant point I was missing.
> > There is plenty of exisiting functionality, New Layer, Delete; Arrange
> > Forwards, Backwards; Show All/None, Current Only, Invert; Layer properties
> > (ie rename the layer).
> To keep the menu managable, I'd suggest having a Visible submenu for
> changing which layers are visible, and similarly a Connectable submenu.
yup probably will have a view/visible submenu will probably be needed.
> > I should be able to figure out eventually how to add easier features like
> > Duplicate Layer, New Layer from Cut/Copy, and Merge (hopefully very
> > similar to grouping and ungrouping)
> Not exactly the same as grouping/ungrouping, as there is no object in
> the diagram involved. Should make it easier, but you'd still have to
> add the undo objects for it.
> > (Alt+L is being used as shortcut for Tools/Line which would need to be
> > changed but I'm sure Dia will have single letter bindings again whenever
> > the text entry is overhauled).
> You'll notice that I have reserved Alt keybindings for the tools. I'd
> like to keep it that way.
Yeah but things like Alt+F are needed to access the _File menu
Alt+E for the _Edit menu etc
it is unfortunate that the text input prevents us from using single letter
bindings for the tools for now.