On Mon, 21 Jul 2008 21:19:16 +0200, Jean-Philippe skateinmars@skateinmars.net wrote:
Hey,
That said, I think the killer feature would be the capacity to edit this submenu (adding/removing predefined or custom actions on different contexts -document, line, word etc...-) :-)
I just played a little bit with this idea (actually longer than I should have) and my results are in the 'dynamic-editor-menu' branch.
It uses GtkUIManager to build the editor menu and makes it more easy to customise by editing ui_editor_menu.xml which is installed in $prefix/share/geany and can/should be copied into ~/.geany when modified. The code first reads it from ~/.geany, if this has failed it tries to read the global one.
Anyway, feel warned this code is more or less just for testing and probably still buggy (I didn't do much testing).
Advantages over the editor menu defined in geany.glade: - less code - to some extend user-customisable - easier to add/change menu items
Disadvantages: - no shown keybinding accelerators (maybe I just didn't find the way right to show them, tried 20 different things, anyway most other popup menus also don't show accelerators so this might be not that surprising) - users can only move or remove menu items, new ones can't be added (also not that bad) - users can't create new submenus - I had to add ugly hacks to get the Send Selection To, Insert Date and Insert Includes menus working (see the ugly Dummy actions). There is maybe a better, cleaner way to achieve this - Currently, the mentioned submenus can't change their pre-defined submenu level otherwise they won't work anymore
So, after all, first I was impressed because I could very quickly build the current menu with the new code. But the three mentioned submenus are causing ugly problems as they are generated manually in Geany and so currently some hacks are necessary (the gtk_ui_manager_get_widget () calls in ui_utils.c are ugly as they use the hardcoded path of an item and this is what we want to have customisable). There should be a way to do the necessary operations on the corresponding actions instead of widgets but that's maybe not possible.
Conclusion: a) while working on it, I realised that it might be not worth to actually use this code. Just drop your comments, ideas, objections here. b) even if we drop this code and keep the old editor menu without customisation, I'm sure we can use the GtkUIManager class to build the toolbar and make it so much more customisable than it is currently. There are less dynamically created items and there it should make really more sense.
Oh, Dominic suggested on IRC to use XUL or something similar. Hmm, I guess XUL can't be used stand-alone and installing all of the xulrunner suite for a customisable popup menu is a no-go. Anyway, there is libglade. But it's an additional dependency and I don't like this just for a popup menu. The best solution would might be the GtkBuilder class which could do the job but it's only available since GTK 2.12. So, it gets also a no. Anything left?
Yay, I'm finished.
Regards, Enrico