Hi,
I have a really strange problem with Geany.
Using Geany 0.17 standard install on open suse 11.0, logged in as a different user to where I was developing Geany so there is no leakage from development versions.
When typing 's' the save as dialog pops up?? I have a keybinding <super>s for save as but undefining it didn't fix the problem but it did let me check that <super> isn't stuck on. It seems to depend on Geany a <super> keybinding existing when Geany is opened.
I can turn the problem on and off by closing Geany with the <super>s keybinding defined and next time I open Geany typing s invokes the keybinding. If I undefine the keybinding and close and re-open the problem has gone away. Its like the <super> is permanently defined so when there is a keybinding using it then typing just the character s is interpreted as <super>s. I tried defining several <super><character> keys and all of them react the same way, when first defining the keybinding all is well, but on closing and re-opening Geany the strange behavior starts. Removing the keybinding does not fix the problem until Geany is closed and re-started. So the problem may be in the load of keybindings. ~/.config/geany/keybindings.conf contains the <Super>s as expected.
Cheers Lex
On Thu, 30 Jul 2009 20:05:01 +1000 Lex Trotman elextr@gmail.com wrote:
Hi,
I have a really strange problem with Geany.
Using Geany 0.17 standard install on open suse 11.0, logged in as a different user to where I was developing Geany so there is no leakage from development versions.
When typing 's' the save as dialog pops up?? I have a keybinding <super>s for save as but undefining it didn't fix the problem but it did let me check that <super> isn't stuck on. It seems to depend on Geany a <super> keybinding existing when Geany is opened.
I can turn the problem on and off by closing Geany with the <super>s keybinding defined and next time I open Geany typing s invokes the keybinding. If I undefine the keybinding and close and re-open the problem has gone away. Its like the <super> is permanently defined so when there is a keybinding using it then typing just the character s is interpreted as <super>s. I tried defining several <super><character> keys and all of them react the same way, when first defining the keybinding all is well, but on closing and re-opening Geany the strange behavior starts. Removing the keybinding does not fix the problem until Geany is closed and re-started. So the problem may be in the load of keybindings. ~/.config/geany/keybindings.conf contains the <Super>s as expected.
I'm not clear, does pressing a <Super>s keybinding actually work at first (and s works normally)? What is the exact string shown in the keybinding prefs treeview?
On my system I just found I can't even set a <Super>s binding, the dialog just picks up 's'. It understands the Super key on its own, but not as a modifier. (I have GTK 2.12.5, Xfce 4.4).
I had a look at kb_keytype_dialog_response_cb(), perhaps it's a GDK bug?
Regards, Nick
2009/7/30 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 30 Jul 2009 20:05:01 +1000 Lex Trotman elextr@gmail.com wrote:
Hi,
I have a really strange problem with Geany.
Using Geany 0.17 standard install on open suse 11.0, logged in as a different user to where I was developing Geany so there is no leakage from development versions.
When typing 's' the save as dialog pops up?? I have a keybinding <super>s for save as but undefining it didn't fix the problem but it did let me check that <super> isn't stuck on. It seems to depend on Geany a <super> keybinding existing when Geany is opened.
I can turn the problem on and off by closing Geany with the <super>s keybinding defined and next time I open Geany typing s invokes the keybinding. If I undefine the keybinding and close and re-open the problem has gone away. Its like the <super> is permanently defined so when there is a keybinding using it then typing just the character s is interpreted as <super>s. I tried defining several <super><character> keys and all of them react the same way, when first defining the keybinding all is well, but on closing and re-opening Geany the strange behavior starts. Removing the keybinding does not fix the problem until Geany is closed and re-started. So the problem may be in the load of keybindings. ~/.config/geany/keybindings.conf contains the <Super>s as expected.
I'm not clear, does pressing a <Super>s keybinding actually work at first (and s works normally)?
Yes until Geany is closed and re-opened. I have had time to stick a couple of printfs in to see what was saved and read from the keybindings file, kb->key=115 kb->mods=0x4000000 written and read and are correct. But I can't see where the accelerators are added after the dialog is finished to see if it is different to keybindings.c/apply_kb_accel
What is the exact string shown in the
keybinding prefs treeview?
<Super>s that is, it actually includes the <> characters and the same in keybindings.conf
Super by itself shows Super_L with no <> which is correct iaw GDK_ksysyms.h
On my system I just found I can't even set a <Super>s binding, the dialog just picks up 's'. It understands the Super key on its own, but not as a modifier. (I have GTK 2.12.5, Xfce 4.4).
Mine is GTK 2.12.9 Gnome 2.22.1 x86_64 platform.
I had a look at kb_keytype_dialog_response_cb(), perhaps it's a GDK bug?
Maybe, see how & what the prefs dialog is setting it to first since at least the kb structure is being set correctly.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Ok, it may be a GTK bug, I'll describe whats going on & you can decide and tell GTK, I've had zero success dealing with them in the past.
Geany keybindings are captured by keybindings.c/on_key_press_event and don't go to GTK but all other keys go to GTK
When a keybinding is first set Geany does NOT set it as a GTK accelerator, but the above callback catches it and it works fine, and if the binding is a key with a modifier the unmodified keys go to GTK and work fine
When keybindings are loaded from file (ie when Geany is closed and re-opened) they are set as GTK accelerators but are still caught by on_key_press_event before GTK. But if the binding is a key with a modifier the unmodified key goes to GTK which appears to erroneously interpret it as an accelerator if the modifier in the gtk_widget_set_accelerator was GDK_SUPER_MASK
The reason you can't set super as a modifier may be that the default modifier mask is set to block it. I don't know what sets it, mine is 1c00000d which allows super at 4000000 and thats the value when the accelerator is set and when the keypress event occurs.
Why does Geany process the accelerators twice? Once in Geany and once in GTK. It seems to me that keybindings don't actually need to be set as accelerators since on_key_press_event catches them all first, and that would work around the GTK problem.
Cheers Lex
2009/7/30 Lex Trotman elextr@gmail.com:
2009/7/30 Nick Treleaven nick.treleaven@btinternet.com:
On Thu, 30 Jul 2009 20:05:01 +1000 Lex Trotman elextr@gmail.com wrote:
Hi,
I have a really strange problem with Geany.
Using Geany 0.17 standard install on open suse 11.0, logged in as a different user to where I was developing Geany so there is no leakage from development versions.
When typing 's' the save as dialog pops up?? I have a keybinding <super>s for save as but undefining it didn't fix the problem but it did let me check that <super> isn't stuck on. It seems to depend on Geany a <super> keybinding existing when Geany is opened.
I can turn the problem on and off by closing Geany with the <super>s keybinding defined and next time I open Geany typing s invokes the keybinding. If I undefine the keybinding and close and re-open the problem has gone away. Its like the <super> is permanently defined so when there is a keybinding using it then typing just the character s is interpreted as <super>s. I tried defining several <super><character> keys and all of them react the same way, when first defining the keybinding all is well, but on closing and re-opening Geany the strange behavior starts. Removing the keybinding does not fix the problem until Geany is closed and re-started. So the problem may be in the load of keybindings. ~/.config/geany/keybindings.conf contains the <Super>s as expected.
I'm not clear, does pressing a <Super>s keybinding actually work at first (and s works normally)?
Yes until Geany is closed and re-opened. I have had time to stick a couple of printfs in to see what was saved and read from the keybindings file, kb->key=115 kb->mods=0x4000000 written and read and are correct. But I can't see where the accelerators are added after the dialog is finished to see if it is different to keybindings.c/apply_kb_accel
What is the exact string shown in the
keybinding prefs treeview?
<Super>s that is, it actually includes the <> characters and the same in keybindings.conf
Super by itself shows Super_L with no <> which is correct iaw GDK_ksysyms.h
On my system I just found I can't even set a <Super>s binding, the dialog just picks up 's'. It understands the Super key on its own, but not as a modifier. (I have GTK 2.12.5, Xfce 4.4).
Mine is GTK 2.12.9 Gnome 2.22.1 x86_64 platform.
I had a look at kb_keytype_dialog_response_cb(), perhaps it's a GDK bug?
Maybe, see how & what the prefs dialog is setting it to first since at least the kb structure is being set correctly.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi, Sorry for the delay.
On Fri, 31 Jul 2009 12:07:55 +1000 Lex Trotman elextr@gmail.com wrote:
Ok, it may be a GTK bug, I'll describe whats going on & you can decide and tell GTK, I've had zero success dealing with them in the past.
Geany keybindings are captured by keybindings.c/on_key_press_event and don't go to GTK but all other keys go to GTK
When a keybinding is first set Geany does NOT set it as a GTK accelerator, but the above callback catches it and it works fine, and if the binding is a key with a modifier the unmodified keys go to GTK and work fine
When keybindings are loaded from file (ie when Geany is closed and re-opened) they are set as GTK accelerators but are still caught by on_key_press_event before GTK. But if the binding is a key with a modifier the unmodified key goes to GTK which appears to erroneously interpret it as an accelerator if the modifier in the gtk_widget_set_accelerator was GDK_SUPER_MASK
Not quite understanding this, perhaps it's better if you report that ;-)
The reason you can't set super as a modifier may be that the default modifier mask is set to block it. I don't know what sets it, mine is 1c00000d which allows super at 4000000 and thats the value when the accelerator is set and when the keypress event occurs.
Mine is 67108864, so should work.
Why does Geany process the accelerators twice? Once in Geany and once
Because we haven't found an easy way to update accelerators during runtime.
in GTK. It seems to me that keybindings don't actually need to be set as accelerators since on_key_press_event catches them all first, and that would work around the GTK problem.
Yes, but this provides handy information to the user so they don't need to lookup the keybinding.
Regards, Nick
On Tue, 11 Aug 2009 12:14:51 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
The reason you can't set super as a modifier may be that the default modifier mask is set to block it. I don't know what sets it, mine is 1c00000d which allows super at 4000000 and thats the value when the accelerator is set and when the keypress event occurs.
Mine is 67108864, so should work.
Sorry, that's wrong. But it seems right anyway:
(gdb) p (void*)GDK_MODIFIER_MASK $5 = (void *) 0x5c001fff (gdb) p (void*) (GDK_MODIFIER_MASK & GDK_SUPER_MASK) $8 = (void *) 0x4000000
Regards, Nick
Hi,
2009/8/11 Nick Treleaven nick.treleaven@btinternet.com:
Hi, Sorry for the delay.
No problem
On Fri, 31 Jul 2009 12:07:55 +1000 Lex Trotman elextr@gmail.com wrote:
Ok, it may be a GTK bug, I'll describe whats going on & you can decide and tell GTK, I've had zero success dealing with them in the past.
Geany keybindings are captured by keybindings.c/on_key_press_event and don't go to GTK but all other keys go to GTK
When a keybinding is first set Geany does NOT set it as a GTK accelerator, but the above callback catches it and it works fine, and if the binding is a key with a modifier the unmodified keys go to GTK and work fine
When keybindings are loaded from file (ie when Geany is closed and re-opened) they are set as GTK accelerators but are still caught by on_key_press_event before GTK. But if the binding is a key with a modifier the unmodified key goes to GTK which appears to erroneously interpret it as an accelerator if the modifier in the gtk_widget_set_accelerator was GDK_SUPER_MASK
Not quite understanding this, perhaps it's better if you report that ;-)
I'll see if I get time to make a minimal GTK program to show the problem.
The reason you can't set super as a modifier may be that the default modifier mask is set to block it. I don't know what sets it, mine is 1c00000d which allows super at 4000000 and thats the value when the accelerator is set and when the keypress event occurs.
Mine is 67108864, so should work.
Why does Geany process the accelerators twice? Once in Geany and once
Because we haven't found an easy way to update accelerators during runtime.
in GTK. It seems to me that keybindings don't actually need to be set as accelerators since on_key_press_event catches them all first, and that would work around the GTK problem.
Yes, but this provides handy information to the user so they don't need to lookup the keybinding.
Of course, it should update the accelerator on the menu!!!
But it actually doesn't until I close and re-open Geany, and then some seem to be pretty persistent, if a keybinding of the standard ones eg Ctrl o for open is re-assigned it actually still says Ctrl o on the open menu item but executes the re-assigned action even after closing and re-opening Geany.
As to how to do it at runtime I'm not sure, but can't you just call gtk_widget_accelerator_remove with the old one and then gtk_accelerator_add with the new one?
Assuming they work right of course ;-)
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 11 Aug 2009 23:37:44 +1000 Lex Trotman elextr@gmail.com wrote:
in GTK. It seems to me that keybindings don't actually need to be set as accelerators since on_key_press_event catches them all first, and that would work around the GTK problem.
Yes, but this provides handy information to the user so they don't need to lookup the keybinding.
Of course, it should update the accelerator on the menu!!!
But it actually doesn't until I close and re-open Geany, and then some seem to be pretty persistent, if a keybinding of the standard ones eg Ctrl o for open is re-assigned it actually still says Ctrl o on the open menu item but executes the re-assigned action even after closing and re-opening Geany.
Yes, I think this is explained in the manual. Stock icons have a fixed accelerator.
As to how to do it at runtime I'm not sure, but can't you just call gtk_widget_accelerator_remove with the old one and then gtk_accelerator_add with the new one?
Nope ;-)
Regards, Nick
Hi Nick,
I've got good news and bad? news.
Since the project I'm working on is going to use gtkmm I was able to spend the day generating "my first gtkmm program" which just happens to try out accelerator keys . I couldn't use C because then I wouldn't have been able to charge it to the project training budget ;-).
I've attached a simple program which demonstrates the super modifier problem, so the good news is, it isn't a Geany problem. I will raise a GTK bug.
The bad? news is that the program also demonstrates that accelerators can be removed and new ones added and they update the UI nicely. Each time you activate the button either by accelerator key or by clicking the menu the accelerator key is incremented.
Note that I had to keep the accel group around to pass it to the remove call, I'm not sure Geany creates once and uses the same accel_group everywhere, that may have been the problem if it didn't work for you in the past.
Or maybe it was a bug in the past :-) Note the documentation note that says they can't be changed means that they can't be *changed* like accel_map entries can, not that they can't be removed and a new one added.
But this might make the whole keybinding code much simpler :-)
Or change the whole thing to use gtk_accel_map that does its own loading and saving and all. Or leave it as is, but it is doing extra work and using nested loops as well. Decisions, decisions ...
Cheers Lex
2009/8/11 Nick Treleaven nick.treleaven@btinternet.com:
On Tue, 11 Aug 2009 23:37:44 +1000 Lex Trotman elextr@gmail.com wrote:
in GTK. It seems to me that keybindings don't actually need to be set as accelerators since on_key_press_event catches them all first, and that would work around the GTK problem.
Yes, but this provides handy information to the user so they don't need to lookup the keybinding.
Of course, it should update the accelerator on the menu!!!
But it actually doesn't until I close and re-open Geany, and then some seem to be pretty persistent, if a keybinding of the standard ones eg Ctrl o for open is re-assigned it actually still says Ctrl o on the open menu item but executes the re-assigned action even after closing and re-opening Geany.
Yes, I think this is explained in the manual. Stock icons have a fixed accelerator.
What a pain, in that case they shouldn't be in the keybindings menu and their accelerator shouldn't be available for assignment to another function.
As to how to do it at runtime I'm not sure, but can't you just call gtk_widget_accelerator_remove with the old one and then gtk_accelerator_add with the new one?
Nope ;-)
Yup, ;-)
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 12 Aug 2009 13:48:21 +1000 Lex Trotman elextr@gmail.com wrote:
I've attached a simple program which demonstrates the super modifier problem, so the good news is, it isn't a Geany problem. I will raise a GTK bug.
OK.
The bad? news is that the program also demonstrates that accelerators can be removed and new ones added and they update the UI nicely. Each time you activate the button either by accelerator key or by clicking the menu the accelerator key is incremented.
Note that I had to keep the accel group around to pass it to the remove call, I'm not sure Geany creates once and uses the same accel_group everywhere, that may have been the problem if it didn't work for you in the past.
Hmm, not sure. Anyway it's great you found out how to do it. Seems simple now, but we couldn't figure it out...
Or maybe it was a bug in the past :-) Note the documentation note that says they can't be changed means that they can't be *changed* like accel_map entries can, not that they can't be removed and a new one added.
Yes, this was confusing.
But this might make the whole keybinding code much simpler :-)
Not sure, there are keybindings that don't have a menu item associated with it.
Or change the whole thing to use gtk_accel_map that does its own loading and saving and all. Or leave it as is, but it is doing extra work and using nested loops as well. Decisions, decisions ...
I haven't looked at gtk_accel_map, perhaps it's easier to keep the existing code. Anyway at some point we can fix this.
Regards, Nick
2009/8/12 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 12 Aug 2009 13:48:21 +1000 Lex Trotman elextr@gmail.com wrote:
I've attached a simple program which demonstrates the super modifier problem, so the good news is, it isn't a Geany problem. I will raise a GTK bug.
OK.
The bad? news is that the program also demonstrates that accelerators can be removed and new ones added and they update the UI nicely. Each time you activate the button either by accelerator key or by clicking the menu the accelerator key is incremented.
Note that I had to keep the accel group around to pass it to the remove call, I'm not sure Geany creates once and uses the same accel_group everywhere, that may have been the problem if it didn't work for you in the past.
Hmm, not sure. Anyway it's great you found out how to do it. Seems simple now, but we couldn't figure it out...
Or maybe it was a bug in the past :-) Note the documentation note that says they can't be changed means that they can't be *changed* like accel_map entries can, not that they can't be removed and a new one added.
Yes, this was confusing.
But this might make the whole keybinding code much simpler :-)
Not sure, there are keybindings that don't have a menu item associated with it.
It just needs to be some widget that the signal can be delivered to.
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
Or change the whole thing to use gtk_accel_map that does its own loading and saving and all. Or leave it as is, but it is doing extra work and using nested loops as well. Decisions, decisions ...
I haven't looked at gtk_accel_map, perhaps it's easier to keep the existing code. Anyway at some point we can fix this.
I'm not suggesting rushing into this, IMHO gtk_accel_map is quite poorly documented & I am not sure I totally understand about accelerator paths but it seems the future direction.
Leaving it as is only has the downside of some overhead although the menu accelerator labels are not being updated until Geany is restarted which could be confusing.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 12 Aug 2009 21:48:08 +1000 Lex Trotman elextr@gmail.com wrote:
But this might make the whole keybinding code much simpler :-)
Not sure, there are keybindings that don't have a menu item associated with it.
It just needs to be some widget that the signal can be delivered to.
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
We have. Probably we could/should add some matching menu items, and IIUC use the relevant widget for the focus commands. There are some special cases though where some keybindings take precedence, so I don't think we can simplify the code that much.
Or change the whole thing to use gtk_accel_map that does its own loading and saving and all. Or leave it as is, but it is doing extra work and using nested loops as well. Decisions, decisions ...
I haven't looked at gtk_accel_map, perhaps it's easier to keep the existing code. Anyway at some point we can fix this.
I'm not suggesting rushing into this, IMHO gtk_accel_map is quite poorly documented & I am not sure I totally understand about accelerator paths but it seems the future direction.
Are there any advantages in doing this?
Leaving it as is only has the downside of some overhead although the
Not sure the overhead is all that significant.
menu accelerator labels are not being updated until Geany is restarted which could be confusing.
At the least, we could use gtk_widget_remove_accelerator ;-)
Regards, Nick
2009/8/13 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 12 Aug 2009 21:48:08 +1000 Lex Trotman elextr@gmail.com wrote:
But this might make the whole keybinding code much simpler :-)
Not sure, there are keybindings that don't have a menu item associated with it.
It just needs to be some widget that the signal can be delivered to.
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
We have. Probably we could/should add some matching menu items, and IIUC use the relevant widget for the focus commands. There are some special cases though where some keybindings take precedence, so I don't think we can simplify the code that much.
Adding menu items is worth while from a user point of view even if it doesn't improve the code.
I for one am unlikely to find functionality that is *only* available from keybindings since that would require reading and remembering the manual (unlikely ;-) or reading the keybindings (which is also unlikely). Whereas searching the menus has a long and honourable? tradition.
Or change the whole thing to use gtk_accel_map that does its own loading and saving and all. Or leave it as is, but it is doing extra work and using nested loops as well. Decisions, decisions ...
I haven't looked at gtk_accel_map, perhaps it's easier to keep the existing code. Anyway at some point we can fix this.
I'm not suggesting rushing into this, IMHO gtk_accel_map is quite poorly documented & I am not sure I totally understand about accelerator paths but it seems the future direction.
Are there any advantages in doing this?
Leaving it as is only has the downside of some overhead although the
Not sure the overhead is all that significant.
Agree, if no one has complained...
menu accelerator labels are not being updated until Geany is restarted which could be confusing.
At the least, we could use gtk_widget_remove_accelerator ;-)
Yeah, getting the user visible things fixed is more important, but after the binding is changed you probably need to run gtk_widget_add_accelerator as well ;-) (it isn't at the moment)
Note remove/add accel works on stock menu items too (just tried it) so my previous comment that they should not be available for change is revoked. It may not be advisable to change them but I don't support preventing things that are inadvisable so long as they don't damage anything.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 13 Aug 2009 08:32:48 +1000 Lex Trotman elextr@gmail.com wrote:
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
We have. Probably we could/should add some matching menu items, and IIUC use the relevant widget for the focus commands. There are some special cases though where some keybindings take precedence, so I don't think we can simplify the code that much.
Adding menu items is worth while from a user point of view even if it doesn't improve the code.
I for one am unlikely to find functionality that is *only* available from keybindings since that would require reading and remembering the manual (unlikely ;-) or reading the keybindings (which is also unlikely). Whereas searching the menus has a long and honourable? tradition.
I agree.
menu accelerator labels are not being updated until Geany is restarted which could be confusing.
At the least, we could use gtk_widget_remove_accelerator ;-)
Yeah, getting the user visible things fixed is more important, but after the binding is changed you probably need to run gtk_widget_add_accelerator as well ;-) (it isn't at the moment)
That's what I meant ;-)
Note remove/add accel works on stock menu items too (just tried it) so my previous comment that they should not be available for change is revoked. It may not be advisable to change them but I don't support preventing things that are inadvisable so long as they don't damage anything.
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Regards, Nick
On Thu, 13 Aug 2009 17:35:52 +0100, Nick wrote:
On Thu, 13 Aug 2009 08:32:48 +1000 Lex Trotman elextr@gmail.com wrote:
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
We have. Probably we could/should add some matching menu items, and IIUC use the relevant widget for the focus commands. There are some special cases though where some keybindings take precedence, so I don't think we can simplify the code that much.
Adding menu items is worth while from a user point of view even if it doesn't improve the code.
I for one am unlikely to find functionality that is *only* available from keybindings since that would require reading and remembering the manual (unlikely ;-) or reading the keybindings (which is also unlikely). Whereas searching the menus has a long and honourable? tradition.
I agree.
Not sure whether I do. In general, you are right. "Hiding" functionality only in keybindings is not the best way. But OTOH adding tons of new menu items just to have them is also not the smartest way, I think. IIRC one of the reasons not adding menu items for each single possible keybinding was to not clutter and bloat the menus too much, And IMO this is still true and still important.
Regards, Enrico
2009/8/14 Enrico Tröger enrico.troeger@uvena.de:
On Thu, 13 Aug 2009 17:35:52 +0100, Nick wrote:
On Thu, 13 Aug 2009 08:32:48 +1000 Lex Trotman elextr@gmail.com wrote:
I hope that you havn't violated the "good GUI guidelines" by having functionality that is only available via keybindings and not by menu ;-)
We have. Probably we could/should add some matching menu items, and IIUC use the relevant widget for the focus commands. There are some special cases though where some keybindings take precedence, so I don't think we can simplify the code that much.
Adding menu items is worth while from a user point of view even if it doesn't improve the code.
I for one am unlikely to find functionality that is *only* available from keybindings since that would require reading and remembering the manual (unlikely ;-) or reading the keybindings (which is also unlikely). Whereas searching the menus has a long and honourable? tradition.
I agree.
Not sure whether I do. In general, you are right. "Hiding" functionality only in keybindings is not the best way. But OTOH adding tons of new menu items just to have them is also not the smartest way, I think. IIRC one of the reasons not adding menu items for each single possible keybinding was to not clutter and bloat the menus too much, And IMO this is still true and still important.
Yes, its a personal judgement call and no two people will totally agree :-) Having looked at the keybindings in detail I agree that some of them don't make sense as menu items, particularly the following areas: Snippets & completion Scrolling Focus Notebook Tabs Toggle fold
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Some of the less commonly used existing menu items could also move into these submenus so actually reducing the size of the top level menus. We better be careful, this could spark another GUI discussion ;-)
On a related but different topic.
I have been toying with the idea of adding a simple action recorder/replayer by recording key presses (in on_key_press_event function) and capturing menu activations by a signal emission hook on the activate signal. My question is, are there any actions that don't use one of these paths, and are there any that use both, for example any key presses that go to GTK and activate menus rather than call the callbacks directly in on_key_press_event or any other actions that are invoked directly without an activate signal? This is something I'll look at in detail after the build-system is finished.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Yes, its a personal judgement call and no two people will totally agree :-) Having looked at the keybindings in detail I agree that some of them don't make sense as menu items, particularly the following areas: Snippets & completion Scrolling Focus Notebook Tabs Toggle fold
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Thanks for posting these, I never knew any of them, although they all sound totally usefull! (I guess I'm in favor of adding them to the menus for that reason :) ).
Best regards.
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list. However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
We better be careful, this could spark another GUI discussion ;-)
I guess it's already too late, haha.
I have been toying with the idea of adding a simple action recorder/replayer by recording key presses (in on_key_press_event
Maybe it's best to try realising this as a plugin from the beginning. There are certainly things missing in the API right now but missing bits could be added. As a plugin, your new code wouldn't affect the core, so reduces the risk of serious bugs (keybinding management is somewhat essential for an editor :D) and keeps independent.
function) and capturing menu activations by a signal emission hook on the activate signal.
How do you mean that? Do you want to connect to the activate signal of each single menu item? Maybe this can be avoided by connecting to the "button-press-event" or maybe better "button-release-event" of the main window ('main_widgets.window') and inside the handler determine which widget actually was activated. Not completely sure whether this will work but I think so. This way you don't need to modify any or at least not much code in Geany itself. Just an idea.
My question is, are there any actions that don't use one of these paths, and are there any that use both, for example any key presses that go to GTK and activate menus rather than call the callbacks directly in on_key_press_event or any other actions that are invoked directly without an activate signal?
Hmm, probably :(. Some keybindings call "activate" in callbacks.c of the corresponding menu items, other keybindings have their own code to do something and some other keybindings call other Geany functions directly which are also called from "activate" handlers. This certainly can be improved and unified but so far it just worked. For details, just have a look in src/keybindings.c and walk through the various handlers. But in general, all key presses should go first into on_key_press_event(), mouse actions are not that easy to handle I think as described above.
Regards, Enrico
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list.
Note that this is only for 0.17, I'm not sure how many more 0.18 will add.
However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
My apologies, I was trying to suggest adding a new submenu of either the edit menu or the right click popup menu, so the third column legend is:
popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu
Where more than one is listed on the same line I am suggesting putting the item in both. I was running out of time at the end so the quote marks mean "as above"
We better be careful, this could spark another GUI discussion ;-)
I guess it's already too late, haha.
I have been toying with the idea of adding a simple action recorder/replayer by recording key presses (in on_key_press_event
Maybe it's best to try realising this as a plugin from the beginning. There are certainly things missing in the API right now but missing bits could be added. As a plugin, your new code wouldn't affect the core, so reduces the risk of serious bugs (keybinding management is somewhat essential for an editor :D) and keeps independent.
Yeah sure.
function) and capturing menu activations by a signal emission hook on the activate signal.
How do you mean that? Do you want to connect to the activate signal of each single menu item? Maybe this can be avoided by connecting to the "button-press-event" or maybe better "button-release-event" of the main window ('main_widgets.window') and inside the handler determine which widget actually was activated. Not completely sure whether this will work but I think so. This way you don't need to modify any or at least not much code in Geany itself. Just an idea.
I thought about just recording keypresses, thats simple, but means the user can only record things that have keypress shortcuts and they have to use the keypress.
I don't think that it is necessary to explicitly connect to each widget's activate, I havn't tried it yet, but g_signal_add_emission_hook claims to add one handler to catch all signals of a specified type, (ie "activate") to a specified *type* of widget (ie menu_item), it then tells you which menu-item widget was the target, so it could successfully be added in a plugin to monitor the main application. I'm not sure if it would work for keypresses too, maybe hooking into "key-press-event" for type widget would work. It would need trying.
Then in playback I can emit activate signals to the particular menu-item widgets or key-press event signals so I don't care how they are processed in Geany.
The problem would be if a user key-press emitted an activate signal on a menu-item I would see it twice :-P hence the question below. Since that is the case, it is going to be very messy trying to "know" which are repeated so they can be ignored.
This is just me thinking out loud ... In general the handlers don't know that they are activated by keypress or menu click so they can't do anything about it. In general key_press_event doesn't know that the closure it calls for a key sequence is going to emit an activate signal so it can't do anything about it. If every key press was processed by GTK's accelerator code then a signal is always emitted and can be recorded. Mostly then the handler would not need to issue another signal, but if it did, it would know to tell the recorder that it was not to be recorded (how? merely an implementation detail ;-). Those key sequences that are not associated with a menu item can have all their closures associated with some sort of g_object that isn't visible, a widget that isn't added to a visible parent should do, and then they can be activated by signals like the rest.
Of course changing the internal operation of Geany keybindings makes the whole exercise much more intrusive than just adding a plugin, but then keybindings.c still needs to be fixed to update the menu accel labels without having to close and re-open Geany, and that will require some work.
Hmmmm... Maybe just recording keypresses is the way to go, at least at first. It shouldn't need any more plugin interface so long as emission-hooks on keypresses work, replay can just emit keypress events & call gtk_main_iteration_do. As I said maybe I'll try after build-system is in the trunk.
That raises the question of what functions can't be assigned to keypresses? AFAICT there are not many editing type actions not available via keypress even if they may not have a default binding. There are some settings type menu items (eg set encodings) but then they are not likely to be used in record replays.
I don't know how likely activating other plugins during recording is going to be or if their actions can be bound to keys?
In build-system branch some of the build commands can't be bound to keypresses but again unlikely to be used in record/replay.
Does menu->edit->delete do any thing different to pressing the delete key? It isn't in the keybinding menu.
Have I missed any?
My question is, are there any actions that don't use one of these paths, and are there any that use both, for example any key presses that go to GTK and activate menus rather than call the callbacks directly in on_key_press_event or any other actions that are invoked directly without an activate signal?
Hmm, probably :(. Some keybindings call "activate" in callbacks.c of the corresponding menu items, other keybindings have their own code to do something and some other keybindings call other Geany functions directly which are also called from "activate" handlers. This certainly can be improved and unified but so far it just worked. For details, just have a look in src/keybindings.c and walk through the various handlers. But in general, all key presses should go first into on_key_press_event(), mouse actions are not that easy to handle I think as described above.
Mouse events, or at least mouse clicks, are easy to catch with emission-hooks, thats actually the example in the doc. But for record/replay, I don't think clicks are much use, each replay would be to exactly the same position, but if arrow keys were used for navigation the replay would be "relative" to the position where it started.
My initial use-case is when I declare a class in C++ I then copy the member function prototypes to the .cpp file to define them and have to add qualifiers (namespace::class_name:: sequences) in several places on each declaration. This is boring and repetitive but not so repetitive that search/replace can do it, but a replay could, since the general form of the changes is "insert some text, forward a couple of words, and insert some more text, go to end of line, backup over ; insert \n{\n} go to start of next line" and repeat. Now if only it could fill in between the braces too ;-)
Thanks for your thoughts so far.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote:
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list.
Note that this is only for 0.17, I'm not sure how many more 0.18 will add.
However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
My apologies, I was trying to suggest adding a new submenu of either
No need to apologise. Maybe I just didn't try hard enough, anyway, now it's pretty clear (and obvious :).
popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu
Where more than one is listed on the same line I am suggesting putting the item in both.
Ok. But to be honest I really don't want to add *anything* more to the right click popup menu. It's already very big. When considering the Gnome HIG, it's way too big. But I think in our case that's ok as long as we don't fill the menu even more.
For the Edit menu in the file menu, I think we could add a new submenu like "More Actions" or something which then lists the actions you mentioned maybe in more sub menus sorted by categories (as you did above). This way we would not bloat the existing menus really and still gain the benefit of having menu items for most keybindings.
Don't get me wrong, I'm all for it, my only worries are not to bloat the menus too much.
function) and capturing menu activations by a signal emission hook on the activate signal.
How do you mean that? Do you want to connect to the activate signal of each single menu item? Maybe this can be avoided by connecting to the "button-press-event" or maybe better "button-release-event" of the main window ('main_widgets.window') and inside the handler determine which widget actually was activated. Not completely sure whether this will work but I think so. This way you don't need to modify any or at least not much code in Geany itself. Just an idea.
I thought about just recording keypresses, thats simple, but means the user can only record things that have keypress shortcuts and they have to use the keypress.
I don't think that it is necessary to explicitly connect to each widget's activate, I havn't tried it yet, but g_signal_add_emission_hook claims to add one handler to catch all
Ah cool. I didn't know about it. That'd be definitely much cooler than connecting to each widget's activate signal :).
Does menu->edit->delete do any thing different to pressing the delete key? It isn't in the keybinding menu.
Yes.
Sorry for not going into detail with the rest of your mail. I'm very limited in time currently and already spent most of the day with the release.
Regards, Enrico
2009/8/17 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote:
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list.
Note that this is only for 0.17, I'm not sure how many more 0.18 will add.
However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
My apologies, I was trying to suggest adding a new submenu of either
No need to apologise. Maybe I just didn't try hard enough, anyway, now it's pretty clear (and obvious :).
popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu
Where more than one is listed on the same line I am suggesting putting the item in both.
Ok. But to be honest I really don't want to add *anything* more to the right click popup menu. It's already very big. When considering the Gnome HIG, it's way too big. But I think in our case that's ok as long as we don't fill the menu even more.
For the Edit menu in the file menu, I think we could add a new submenu like "More Actions" or something which then lists the actions you mentioned maybe in more sub menus sorted by categories (as you did above). This way we would not bloat the existing menus really and still gain the benefit of having menu items for most keybindings.
Don't get me wrong, I'm all for it, my only worries are not to bloat the menus too much.
Totally agree with all you said.
Maybe submenus of the popup for the inserts and the finds could help shrink it.
To be honest I don't use the popup much, I use keybindings mostly so I am probably not best qualified to say whats common use and whats not & can go to a submenu.
function) and capturing menu activations by a signal emission hook on the activate signal.
How do you mean that? Do you want to connect to the activate signal of each single menu item? Maybe this can be avoided by connecting to the "button-press-event" or maybe better "button-release-event" of the main window ('main_widgets.window') and inside the handler determine which widget actually was activated. Not completely sure whether this will work but I think so. This way you don't need to modify any or at least not much code in Geany itself. Just an idea.
I thought about just recording keypresses, thats simple, but means the user can only record things that have keypress shortcuts and they have to use the keypress.
I don't think that it is necessary to explicitly connect to each widget's activate, I havn't tried it yet, but g_signal_add_emission_hook claims to add one handler to catch all
Ah cool. I didn't know about it. That'd be definitely much cooler than connecting to each widget's activate signal :).
Does menu->edit->delete do any thing different to pressing the delete key? It isn't in the keybinding menu.
Yes.
Sorry for not going into detail with the rest of your mail. I'm very limited in time currently and already spent most of the day with the release.
Thanks for your efforts so far, I really didn't expect an answer until after the release :-) and thanks for the release.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 17 Aug 2009 12:38:22 +1000, Lex wrote:
2009/8/17 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote:
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list.
Note that this is only for 0.17, I'm not sure how many more 0.18 will add.
However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
My apologies, I was trying to suggest adding a new submenu of either
No need to apologise. Maybe I just didn't try hard enough, anyway, now it's pretty clear (and obvious :).
popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu
Where more than one is listed on the same line I am suggesting putting the item in both.
Ok. But to be honest I really don't want to add *anything* more to the right click popup menu. It's already very big. When considering the Gnome HIG, it's way too big. But I think in our case that's ok as long as we don't fill the menu even more.
For the Edit menu in the file menu, I think we could add a new submenu like "More Actions" or something which then lists the actions you mentioned maybe in more sub menus sorted by categories (as you did above). This way we would not bloat the existing menus really and still gain the benefit of having menu items for most keybindings.
Don't get me wrong, I'm all for it, my only worries are not to bloat the menus too much.
Totally agree with all you said.
Maybe submenus of the popup for the inserts and the finds could help shrink it.
Uhhh, dangerous topic :). We already had the find items in a submenu but I voted against it as at least I personally use them a lot from the popup menu and hiding them in a submenu reduces usuability. This might be a pretty personal rationale but I really would like to keep these items as they are :). Though I would agree about the insert items. I also thought about moving them into a plugin (at least 'insert date' and 'insert include...') especially because 'insert include' is very specific to C/C++ and not of any use for other filetypes. But I still didn't come around to actually do it.
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list). Nick?
To be honest I don't use the popup much, I use keybindings mostly so I am probably not best qualified to say whats common use and whats not & can go to a submenu.
Who is qualified to say this at all? Every user has different use cases of the GUI, the keybindings and everything else. It's always hard to make such decisions.
Regards, Enrico
2009/8/18 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 17 Aug 2009 12:38:22 +1000, Lex wrote:
2009/8/17 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote:
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
but I think the following should make it into a menu (actually a submenu, since I don't think they are commonly used enough to go in a top level menu) and I have suggested which new submenu to put them in.
Ctrl-K delete current line popup-edit Ctrl-T transpose current line popup-edit Ctrl-Shift-X cut line popup-edit Ctrl-Shift-C copy line popup-edit Alt-Shift-W select word edit-select and popup-select Alt-Shift-P select para edit-select and popup-select Alt-Shift-L select line edit-select and popup-select insert alt whitspace popup-edit indent space popup-indent undent space popup-indent prev indent popup-indent Ctrl-B matching brace edit-goto popup-goto Ctrl-M toggle marker edit-goto popup-goto Ctrl-. next marker " " Ctrl-, prev marker " "
Cool, thanks for this list.
Note that this is only for 0.17, I'm not sure how many more 0.18 will add.
However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks.
My apologies, I was trying to suggest adding a new submenu of either
No need to apologise. Maybe I just didn't try hard enough, anyway, now it's pretty clear (and obvious :).
popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu
Where more than one is listed on the same line I am suggesting putting the item in both.
Ok. But to be honest I really don't want to add *anything* more to the right click popup menu. It's already very big. When considering the Gnome HIG, it's way too big. But I think in our case that's ok as long as we don't fill the menu even more.
For the Edit menu in the file menu, I think we could add a new submenu like "More Actions" or something which then lists the actions you mentioned maybe in more sub menus sorted by categories (as you did above). This way we would not bloat the existing menus really and still gain the benefit of having menu items for most keybindings.
Don't get me wrong, I'm all for it, my only worries are not to bloat the menus too much.
Totally agree with all you said.
Maybe submenus of the popup for the inserts and the finds could help shrink it.
Uhhh, dangerous topic :). We already had the find items in a submenu but I voted against it as at least I personally use them a lot from the popup menu and hiding them in a submenu reduces usuability. This might be a pretty personal rationale but I really would like to keep these items as they are :). Though I would agree about the insert items. I also thought about moving them into a plugin (at least 'insert date' and 'insert include...') especially because 'insert include' is very specific to C/C++ and not of any use for other filetypes. But I still didn't come around to actually do it.
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list). Nick?
To be honest I don't use the popup much, I use keybindings mostly so I am probably not best qualified to say whats common use and whats not & can go to a submenu.
Who is qualified to say this at all? Every user has different use cases of the GUI, the keybindings and everything else. It's always hard to make such decisions.
Perhaps I could have added, I don't have strong feelings about the popup.
So I'm happy for you to do whatever you think is ok, including not putting anything in the popup and instead putting everything in the main edit menu using an insert submenu for the insert items to make space for one or two submenus That would not change the size of level one of the edit menu.
PS the GTK bug that is the original topic of this thread is fixed.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
It would be nice if you would only quote as much as you're referring to. These full quotes make your emails really hard to read.
Best regards.
Sorry, Gmail hides the quotes and I forget to delete them.
Cheers Lex
2009/8/18 Thomas Martitz thomas.martitz@student.htw-berlin.de:
It would be nice if you would only quote as much as you're referring to. These full quotes make your emails really hard to read.
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 18 Aug 2009 11:04:56 +1000, Lex wrote:
Sorry, Gmail hides the quotes and I forget to delete them.
The amount of the quotes isn't really the problem. I prefer to have rather longer quotes than too short ones or even none as in the mail I'm replying to right now :).
Regards, Enrico
On Tue, 18 Aug 2009 10:39:44 +1000, Lex wrote:
Don't get me wrong, I'm all for it, my only worries are not to bloat the menus too much.
Totally agree with all you said.
Maybe submenus of the popup for the inserts and the finds could help shrink it.
Uhhh, dangerous topic :). We already had the find items in a submenu but I voted against it as at least I personally use them a lot from the popup menu and hiding them in a submenu reduces usuability. This might be a pretty personal rationale but I really would like to keep these items as they are :). Though I would agree about the insert items. I also thought about moving them into a plugin (at least 'insert date' and 'insert include...') especially because 'insert include' is very specific to C/C++ and not of any use for other filetypes. But I still didn't come around to actually do it.
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
So I'm happy for you to do whatever you think is ok, including not
Is this also true in general? I could give you a big, very big list of things you could do for me :).
putting anything in the popup and instead putting everything in the main edit menu using an insert submenu for the insert items to make space for one or two submenus That would not change the size of level one of the edit menu.
Yeah, sounds good. I think it's best to group the currently two insert items into a new submenu and add to the new submenu also ther actions of your list and these changes should be done in both menus, the Edit main menu and the popup menu to keep them somewhat in sync (they are not and they were never nor were they intended to be in sync but at least the 'insert' items are). The bad thing is doing these changes with Glade is annoying, a lot of clicking and such and more heavily, you need to do it all twice for both menus. So if you like to do it, remove the existing submenus from Glade, add the new submenu in Glade and then add the rest of the new menu items in plain C code :). This way you can put the whole code to generate the menu items into a for loop running from 0 to 1 and so save a lot of work, code and most important time. If you don't like to do it, just ignore this, then I will add this to my personal todo list.
PS the GTK bug that is the original topic of this thread is fixed.
Cool.
Regards, Enrico
On Tue, 18 Aug 2009 20:04:12 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
The bad thing is doing these changes with Glade is annoying, a lot of clicking and such and more heavily, you need to do it all twice for both menus. So if you like to do it, remove the existing submenus from Glade, add the new submenu in Glade and then add the rest of the new menu items in plain C code :). This way you can put the whole code to generate the menu items into a for loop running from 0 to 1 and so save a lot of work, code and most important time. If you don't like to do it, just ignore this, then I will add this to my personal todo list.
Hmm, personally I like to use Glade for complicated menus and dialogs.
Maybe the menu could be done in Glade as a separate popup menu, then call create_insert_menu() in interface.c and pack it into the main edit menu, then call create_insert_menu() again and pack that into the popup menu. From looking at the generated code for the create_edit_menu1() editor popup menu this might work, but then any menu items would need to be looked up with the menu as the 'owner' rather than the main menu or editor popup menu widgets.
The same could apply for the Format submenus, and would be more useful as they have more items.
Regards, Nick
On Thu, 20 Aug 2009 11:56:43 +0100, Nick wrote:
Hey,
sorry for the delay.
On Tue, 18 Aug 2009 20:04:12 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
The bad thing is doing these changes with Glade is annoying, a lot of clicking and such and more heavily, you need to do it all twice for both menus. So if you like to do it, remove the existing submenus from Glade, add the new submenu in Glade and then add the rest of the new menu items in plain C code :). This way you can put the whole code to generate the menu items into a for loop running from 0 to 1 and so save a lot of work, code and most important time. If you don't like to do it, just ignore this, then I will add this to my personal todo list.
Hmm, personally I like to use Glade for complicated menus and dialogs.
Maybe the menu could be done in Glade as a separate popup menu, then call create_insert_menu() in interface.c and pack it into the main edit menu, then call create_insert_menu() again and pack that into the popup menu. From looking at the generated code for the create_edit_menu1() editor popup menu this might work, but then any menu items would need to be looked up with the menu as the 'owner' rather than the main menu or editor popup menu widgets.
The same could apply for the Format submenus, and would be more useful as they have more items.
I personally see this as more complicated than the way I suggested. Though I don't have a strong opinion on that.
Whoever wants to implement it, should choose the way he or she prefers. If nobody wants to implement it, I'll do at some point.
Regards, Enrico
On Mon, 17 Aug 2009 23:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
Sounds good. Could perhaps move the 'Find Document Usage' item there as the 'Find Usage' one can often be used instead.
Regards, Nick
On Tue, 18 Aug 2009 15:38:10 +0100, Nick wrote:
On Mon, 17 Aug 2009 23:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
Sounds good. Could perhaps move the 'Find Document Usage' item there as the 'Find Usage' one can often be used instead.
*whine*
Am I really the only one who uses the Find Usage and Find Document Usage items regularly?
Regards, Enrico
2009/8/19 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 18 Aug 2009 15:38:10 +0100, Nick wrote:
On Mon, 17 Aug 2009 23:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
Sounds good. Could perhaps move the 'Find Document Usage' item there as the 'Find Usage' one can often be used instead.
*whine*
Am I really the only one who uses the Find Usage and Find Document Usage items regularly?
I found Find Usage extremely useful when trying to understand how Geany worked, but never used Find Document Usage. With the former I didn't have to worry about where a function gets used, I just click on the message to go to it. Even if its the same document.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 19 Aug 2009 09:01:40 +1000, Lex wrote:
2009/8/19 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 18 Aug 2009 15:38:10 +0100, Nick wrote:
On Mon, 17 Aug 2009 23:11:43 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
Sounds good. Could perhaps move the 'Find Document Usage' item there as the 'Find Usage' one can often be used instead.
*whine*
Am I really the only one who uses the Find Usage and Find Document Usage items regularly?
I found Find Usage extremely useful when trying to understand how Geany worked, but never used Find Document Usage. With the former I didn't have to worry about where a function gets used, I just click on the message to go to it. Even if its the same document.
It can be annoying when you have 30+ files open in a session and search for something you are only interested in the current document but the search text occurs also in other files often. Not sure what I'm doing different, but I often have this case :).
Regards, Enrico
On Tue, 18 Aug 2009 19:55:51 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list).
Sounds good. Could perhaps move the 'Find Document Usage' item there as the 'Find Usage' one can often be used instead.
*whine*
Am I really the only one who uses the Find Usage and Find Document Usage items regularly?
I knew people use the Find Usage menu item regularly, wasn't so sure about the document one. Anyway no need to move it, I just assumed wrongly that it was less commonly used. I suppose I use the equivalent keybinding quite a lot myself.
Regards, Nick
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 14 Aug 2009 11:27:06 +1000 Lex Trotman elextr@gmail.com wrote:
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Well, you have to pass the existing accelerator key + modifier to be able to remove one, so you would need some extra code to lookup the stock accelerator and remove it at startup.
Regards, Nick
2009/8/14 Nick Treleaven nick.treleaven@btinternet.com:
On Fri, 14 Aug 2009 11:27:06 +1000 Lex Trotman elextr@gmail.com wrote:
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Well, you have to pass the existing accelerator key + modifier to be able to remove one, so you would need some extra code to lookup the stock accelerator and remove it at startup.
Well I was assuming that since they are already in the keybinding menu they are looked up from somewhere and that would just stay the same :-)
Interestingly I just realised that my test program is using its own accel group to remove the standard accelerator, but it works!!! Probably should get the global accel group though. Who knows, maybe they just better be taken out the keybinding menu and forbidden. sigh :-S
Comments in the GTK+ bug list seem to show that the developers of GTK are somewhat unhappy with the mess of the accel code and associated bugs, erm undocumented features. I guess these are some of them ;-)
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 15 Aug 2009 11:12:58 +1000, Lex wrote:
2009/8/14 Nick Treleaven nick.treleaven@btinternet.com:
On Fri, 14 Aug 2009 11:27:06 +1000 Lex Trotman elextr@gmail.com wrote:
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Well, you have to pass the existing accelerator key + modifier to be able to remove one, so you would need some extra code to lookup the stock accelerator and remove it at startup.
Well I was assuming that since they are already in the keybinding menu they are looked up from somewhere and that would just stay the same :-)
Interestingly I just realised that my test program is using its own accel group to remove the standard accelerator, but it works!!! Probably should get the global accel group though. Who knows, maybe they just better be taken out the keybinding menu and forbidden. sigh :-S
Comments in the GTK+ bug list seem to show that the developers of GTK are somewhat unhappy with the mess of the accel code and associated bugs, erm undocumented features. I guess these are some of them ;-)
Would you mind to share the link to the mentioned bug report? Thanks.
Regards, Enrico
Sure
http://bugzilla.gnome.org/show_bug.cgi?id=591526
Cheers Lex
2009/8/16 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 15 Aug 2009 11:12:58 +1000, Lex wrote:
2009/8/14 Nick Treleaven nick.treleaven@btinternet.com:
On Fri, 14 Aug 2009 11:27:06 +1000 Lex Trotman elextr@gmail.com wrote:
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Well, you have to pass the existing accelerator key + modifier to be able to remove one, so you would need some extra code to lookup the stock accelerator and remove it at startup.
Well I was assuming that since they are already in the keybinding menu they are looked up from somewhere and that would just stay the same :-)
Interestingly I just realised that my test program is using its own accel group to remove the standard accelerator, but it works!!! Probably should get the global accel group though. Who knows, maybe they just better be taken out the keybinding menu and forbidden. sigh :-S
Comments in the GTK+ bug list seem to show that the developers of GTK are somewhat unhappy with the mess of the accel code and associated bugs, erm undocumented features. I guess these are some of them ;-)
Would you mind to share the link to the mentioned bug report? Thanks.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 16 Aug 2009 11:02:06 +1000, Lex wrote:
Sure
Ok, the bug report hasn't many comments except the duplicate note and the other bug also doesn't give much more clue. Anyway, it seems to be a pure GTK problem.
Regards, Enrico
2009/8/17 Enrico Tröger enrico.troeger@uvena.de:
On Sun, 16 Aug 2009 11:02:06 +1000, Lex wrote:
Sure
Ok, the bug report hasn't many comments except the duplicate note and the other bug also doesn't give much more clue. Anyway, it seems to be a pure GTK problem.
Yeah, I created the problem in one of my own programs outside Geany so there seemed no reason to attribute the bug to Geany.
When I did a search to see if anyone had already reported it I noticed several apps having similar problems hence the note and that triggered someone to mark a gnometerm bug as a duplicate.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 15 Aug 2009 11:12:58 +1000 Lex Trotman elextr@gmail.com wrote:
I've no objection to this, but I probably won't implement overriding stock accelerators myself.
Sorry I don't think I was clear. What I was trying to say was that overriding them will work the same as other accelerators, so no specific implementation is needed. In fact specific action is needed to prevent users overriding them, like the original suggestion of taking them out of the keybinding menu, and I was trying to say that I didn't think it was appropriate or worth the effort.
Well, you have to pass the existing accelerator key + modifier to be able to remove one, so you would need some extra code to lookup the stock accelerator and remove it at startup.
Well I was assuming that since they are already in the keybinding menu they are looked up from somewhere and that would just stay the same :-)
I've implemented changing accels for non-stock main menu accelerators only. (Popup menu accels I'll do later after some implementation change to plugin keybindings so I don't have to break the ABI too often in future).
I tried overriding stock accels, but it didn't seem to work, unless I made a mistake. See patch attached.
Regards, Nick