Hi, I propose we add a new menubar Search submenu which is also shown in the popup editor menu. This would be similar to what we do for the Edit submenu items Format and Commands.
Reasoning:
1. We can help new users to find all the various keybinding commands grouped into logical submenus. 2. We keep the popup editor menu smaller (but make it easy for upgrading users to find the old Find Document Usage and Go to Tag Declaration items [which are currently in the Search menubar]). 3. We keep the menubar Search menu smaller than current HEAD. 4. Sharing the submenu means we only need one actual GtkMenu widget (this is already done for the Edit submenus).
The new submenu would have both Find Usage items and both Go to Tag items (even though one of each are shown in the toplevel popup menu for speed).
Logically, probably the Search->Find Selected items should be moved to the submenu also.
There are also Go to Marker commands in the Edit->Commands menu which would fit better in the new submenu, and other 'Go to' keybindings which don't have menu items.
Thoughts?
Regards, Nick
On 15 September 2010 00:16, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi, I propose we add a new menubar Search submenu which is also shown in the popup editor menu. This would be similar to what we do for the Edit submenu items Format and Commands.
Reasoning:
- We can help new users to find all the various keybinding commands
grouped into logical submenus. 2. We keep the popup editor menu smaller (but make it easy for upgrading users to find the old Find Document Usage and Go to Tag Declaration items [which are currently in the Search menubar]). 3. We keep the menubar Search menu smaller than current HEAD. 4. Sharing the submenu means we only need one actual GtkMenu widget (this is already done for the Edit submenus).
The new submenu would have both Find Usage items and both Go to Tag items (even though one of each are shown in the toplevel popup menu for speed).
Logically, probably the Search->Find Selected items should be moved to the submenu also.
There are also Go to Marker commands in the Edit->Commands menu which would fit better in the new submenu, and other 'Go to' keybindings which don't have menu items.
Thoughts?
As noted in another response, IAW Gnome HIG right click popups S/B context related things.
FWIW I'd:
1. remove undo/redo/select all as they are not context related
2. let the user pick say four most used top level commands since we are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
3. pack the rest in submenus.
Thus we get:
user 1 user 2 user 3 user 4 -------- cut copy paste delete ------- format > format submenu as now insert > insert submenu including the insert comments search > find items and as you say search selected goto > open file, goto line etc
That gives a total top level of 12 which is ok
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 15 Sep 2010 11:15:23 +1000 Lex Trotman elextr@gmail.com wrote:
As noted in another response, IAW Gnome HIG right click popups S/B context related things.
What does S/B mean?
FWIW I'd:
- remove undo/redo/select all as they are not context related
Then are common editor popup menu commands though - gedit and Scite have them. nedit has undo/redo and mousepad has select all.
I'm not particularly opposed to removing them, just mentioning that some users will expect to see them there.
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus.
- pack the rest in submenus.
format > format submenu as now
What about Commands - at least half of these are context related.
insert > insert submenu including the insert comments
I think at least me and Enrico use insert comments a lot, we'd like it to be toplevel. The other insert items could maybe be in a submenu (also insert alt whitespace). This would be like having Go to Tag Definition in toplevel but Go to Tag Declaration in a submenu as it's less common.
search > find items and as you say search selected goto > open file, goto line etc
Personally I would combine search and goto, that way we can share a GtkMenu widget between the search menu and popup menu. This is a good strategy because we don't have to maintain two separate menus if most items are needed in each.
Regards, Nick
On Wed, 15 Sep 2010 15:33:50 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
insert > insert submenu including the insert comments
I think at least me and Enrico use insert comments a lot, we'd like it to be toplevel. The other insert items could maybe be in a submenu (also insert alt whitespace).
Actually, we could have just one toplevel insert item, with the contents of the 'Insert Comments' menu, 'Insert Date' as a new menu item *and* the existing date submenu, plus the other insert items. That way it's no harder to do 'Insert ChangeLog Entry' - we would avoid a cascade of submenus.
Regards, Nick
Hey Nick,
On 16 September 2010 00:33, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 15 Sep 2010 11:15:23 +1000 Lex Trotman elextr@gmail.com wrote:
As noted in another response, IAW Gnome HIG right click popups S/B context related things.
What does S/B mean?
Sorry "should be" I was in a hurry so more acronyms than usual.
FWIW I'd:
- remove undo/redo/select all as they are not context related
Then are common editor popup menu commands though - gedit and Scite have them. nedit has undo/redo and mousepad has select all.
I'm not particularly opposed to removing them, just mentioning that some users will expect to see them there.
Ok, well lets see what others think.
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus.
Ah but whats the most useful?
I *never* use insert comments from the popup and rarely from the menu (changelog mostly) so for me having any insert comments in the popup is a waste of space.
I'm not suggesting its required, but if someone out there has the time to implement it this would remove all the disagreements :-)
- pack the rest in submenus.
format > format submenu as now
What about Commands - at least half of these are context related.
insert > insert submenu including the insert comments
I think at least me and Enrico use insert comments a lot, we'd like it to be toplevel. The other insert items could maybe be in a submenu (also insert alt whitespace). This would be like having Go to Tag Definition in toplevel but Go to Tag Declaration in a submenu as it's less common.
And I of course use the tool differently so I don't want any inserts and use go to declaration much more than go to definition due to the language I use most :-).
For all user names : [insert name here] uses it differently again so almost no one is fully happy with a fixed menu.
search > find items and as you say search selected goto > open file, goto line etc
Personally I would combine search and goto, that way we can share a GtkMenu widget between the search menu and popup menu. This is a good strategy because we don't have to maintain two separate menus if most items are needed in each.
Good idea.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
May be make sense create context menu like in jEdit (context menu in jEdit is editable)? Is really good jEdit feature, and would be very nice if Geany have this feature too.
On Thu, 16 Sep 2010 09:54:09 +1000 Lex Trotman elextr@gmail.com wrote:
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus.
Ah but whats the most useful?
Things which are useful for the largest number of users. There is also an issue of letting new users discover some useful things easily that they might not know Geany does.
I *never* use insert comments from the popup and rarely from the menu (changelog mostly) so for me having any insert comments in the popup is a waste of space.
Which is why a single Insert submenu would be better.
I'm not suggesting its required, but if someone out there has the time to implement it this would remove all the disagreements :-)
Is it so bad to solve the disagreements using submenus?
This avoids maintenance and code complexity of popup configurability, which I predict isn't going to be pretty. C is not a good GUI language.
- pack the rest in submenus.
format > format submenu as now
What about Commands - at least half of these are context related.
insert > insert submenu including the insert comments
I think at least me and Enrico use insert comments a lot, we'd like it to be toplevel. The other insert items could maybe be in a submenu (also insert alt whitespace). This would be like having Go to Tag Definition in toplevel but Go to Tag Declaration in a submenu as it's less common.
And I of course use the tool differently so I don't want any inserts
Did you see my Insert submenu reply?
and use go to declaration much more than go to definition due to the language I use most :-).
Correct me if wrong, but Go to declaration is only needed for function prototypes and extern declarations, no? The feature is only useful for C/C++, not for most users. So having to find it in the proposed popup Search submenu is acceptable, no?
For all user names : [insert name here] uses it differently again so almost no one is fully happy with a fixed menu.
As mentioned above, I'm not trying to force my preferences on anyone. I'm trying to find a good default that is reasonable (but not ideal) for everyone.
Regards, Nick
On Thu, Sep 16, 2010 at 13:57, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 16 Sep 2010 09:54:09 +1000 Lex Trotman elextr@gmail.com wrote:
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus.
Ah but whats the most useful?
Things which are useful for the largest number of users. There is also an issue of letting new users discover some useful things easily that they might not know Geany does.
I *never* use insert comments from the popup and rarely from the menu (changelog mostly) so for me having any insert comments in the popup is a waste of space.
Which is why a single Insert submenu would be better.
I'm not suggesting its required, but if someone out there has the time to implement it this would remove all the disagreements :-)
Is it so bad to solve the disagreements using submenus?
This avoids maintenance and code complexity of popup configurability, which I predict isn't going to be pretty. C is not a good GUI language.
Where I really see an advantage of having the context menu customisable are plugin actions. With my gproject plugin and my not-publicly-released ctags plugin I also added several items at the top of the context menu (plus separators). I can imagine that if several plugins do a similar thing, the context menu gets pretty messy (someone will put the new items to the top, someone to the bottom, someone will use separators, someone not, ...) Also the menu starts growing even if the user doesn't really use the context menu item of the given plugin.
This is why I really like the Lex's idea of having a fixed set of items in the menu that are always present (possibly containing submenus) and a variable set of configurable items. If the configurable items can be arbitrary items from the keybindings list, the plugins won't have to add their own items into the context menu and the user can only pick those he wishes to be present. It's not necessary to have submenus in the customisable part of the menu - a plain list of items would be fine. By default the variable list could also contain the "questionable" entries that someone wishes to be present in the menu and someone not. Those who don't want to have them can just remove them if they wish.
Of course this would require some work...
Jiri
On 16 September 2010 21:57, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 16 Sep 2010 09:54:09 +1000 Lex Trotman elextr@gmail.com wrote:
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus.
Ah but whats the most useful?
Things which are useful for the largest number of users.
A pessimistic interpretation of this is: If its not C we're not interested :-)
There is also
an issue of letting new users discover some useful things easily that they might not know Geany does.
Discovery should be in the main menus that are always visible, not in popups which are hidden.
I *never* use insert comments from the popup and rarely from the menu (changelog mostly) so for me having any insert comments in the popup is a waste of space.
Which is why a single Insert submenu would be better.
Yes, erm I thought thats what I proposed and below you were proposing to also have insert(s) in the top level, my misunderstanding.
I'm not suggesting its required, but if someone out there has the time to implement it this would remove all the disagreements :-)
Is it so bad to solve the disagreements using submenus?
It doesn't solve which commands go in the top level of the popup for greatest convenience, which was the only bit I was suggesting as configurable.
This avoids maintenance and code complexity of popup configurability, which I predict isn't going to be pretty. C is not a good GUI language.
Too true, so make it manually edited configuration for now.
- pack the rest in submenus.
format > format submenu as now
What about Commands - at least half of these are context related.
insert > insert submenu including the insert comments
I think at least me and Enrico use insert comments a lot, we'd like it to be toplevel. The other insert items could maybe be in a submenu (also insert alt whitespace). This would be like having Go to Tag Definition in toplevel but Go to Tag Declaration in a submenu as it's less common.
And I of course use the tool differently so I don't want any inserts
Did you see my Insert submenu reply?
As I said above, I read this as implying you also wanted insert item(s) in the toplevel, not just in the submenu.
and use go to declaration much more than go to definition due to the language I use most :-).
Correct me if wrong, but Go to declaration is only needed for function prototypes and extern declarations, no?
For C, for C++ the function declaration is part of the class declaration and is separate from the definition. The class declaration has more information and is used much more often than the prototype/extern declaration is in C.
The feature is only useful for
C/C++, not for most users. So having to find it in the proposed popup Search submenu is acceptable, no?
Well, if goto definition is in the top level then I'd say no :-) it needs to be the other way round for C++ users. And I would have thought that there were other languages that made the distinction between declarations and definitions, not just C/C++.
For all user names : [insert name here] uses it differently again so almost no one is fully happy with a fixed menu.
As mentioned above, I'm not trying to force my preferences on anyone. I'm trying to find a good default that is reasonable (but not ideal) for everyone.
And I'm trying to suggest that it would be better for users to be able to pick their own ideal.
It may be that no one who is interested has enough time to implement it, even without a GUI, but if we don't ask we won't get :-).
Once at least some configuration is available then things like Jiri's suggestion become possible as further extensions.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Sep 15, 2010 at 03:15, Lex Trotman elextr@gmail.com wrote:
On 15 September 2010 00:16, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi, I propose we add a new menubar Search submenu which is also shown in the popup editor menu. This would be similar to what we do for the Edit submenu items Format and Commands.
Reasoning:
- We can help new users to find all the various keybinding commands
grouped into logical submenus. 2. We keep the popup editor menu smaller (but make it easy for upgrading users to find the old Find Document Usage and Go to Tag Declaration items [which are currently in the Search menubar]). 3. We keep the menubar Search menu smaller than current HEAD. 4. Sharing the submenu means we only need one actual GtkMenu widget (this is already done for the Edit submenus).
The new submenu would have both Find Usage items and both Go to Tag items (even though one of each are shown in the toplevel popup menu for speed).
Logically, probably the Search->Find Selected items should be moved to the submenu also.
There are also Go to Marker commands in the Edit->Commands menu which would fit better in the new submenu, and other 'Go to' keybindings which don't have menu items.
Thoughts?
As noted in another response, IAW Gnome HIG right click popups S/B context related things.
FWIW I'd:
- remove undo/redo/select all as they are not context related
Agree - apart from not being context related basically everyone sane uses keyboard shortcuts for them so they just occupy space.
- let the user pick say four most used top level commands since we
are *never* going to agree on them. Use a simplified version of the customise toolbar dialog.
That would be pretty cool! If the selectable commands are all the commands from the keybindings list, these could also be the commands introduced by plugins, which is something I would find really useful. I think the restriction of four doesn't have to exist at all?
Cheers,
Jiri
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel