part four.
Kephra has a main menu, that is compiled from a yaml file you can open via the "config > interface" menu. So you can change it easily with the previously listed line edit commands. It serves as an overview, sorted by topic. Optimized for finding a function you looking for, not optimized for finding it after the first click, that's the task for context menus. This main menu I refactor from time to time, to keep it structure sense-making, balanced and beautiful.
On the other hand Kephra also has context menus, that are also compiled from yaml (easy changeable), but contain a selection of important commands, associated with this spot in the app. this is almost self evident and widely used in GUI software, but editors miss here large opportunities. Lets take for instance Gvim. true its not a GUI Editor of the first order, but believe me, most IDE don't do much better. GVim has only one context menu with undo, insert and some selecting commands. if you have already selected, the usual 4 edit commands will be added.
Nearly same thing with scite, padre or notepad++. Only notepads menu is extralarge because its polluted withe a shiny but fancy feature for highlighting selections of text with different colors. I currently can't do that because Wxwidgets wraps an 2 years old version of scintilla. but back to context menu. The Kommodo IDE has also an extra long context menu that you have to scroll with tiny menu buttons.
But how does it Kephra? We put also a lot of stuff into the context menu, but copied a very reasonable idea from firefox that anybody else don't seems to notice. Noone of the here named editors and most of the others don't do it, even if its the natural thing to do: don't pollute precious context menu space with calls that don't provide a useful function in this context. or lets put it more clearly: separate this menu into two. one general menu with functions about this current file (undo,redo|insert, select all|back to last edit,search dialog|save,open|close). another menu will popup if you rightclick and you selected some text. then you get a menu of actions you can do with that selected text like:copy, insert, replace, cut, delete|take as search term, take as replace term, put it into notepad,lc,uc). maybe the comment function we should put here too like padre does.
That was nice and menus don't get too long. But it doesn't stop there. if you rightclick on the margin, you get another menu with items that have to do what the margins are about. markers, bookmarks, folding and switching the visibilities of the editpanel margins. I mean its the most natural thing to do: i don't like this so i click on it and say it should go instead of searching the call in the main menu, even all these calls are just in the "view" menu. The searchbar has a context menu where you can set all the search option like in the search and replace dialog. It can also be found in main menu under "search > options". and many status bar cells have a context menu too. its a bit like kommodo does it, but only richer. in kommodo cells that react on left click have an small updown arrow that signal: here can you popup a menu by left click. In kephra left and right click do something different. i mean with left you do point an click or switch buttons. thats what leftclick also do in kephra status cells. the switch between the 2 (in one case 3) most common settings for that document property. but if you rightclick you get an context menu with a lot of more stuff associated with that property. to me its often a way to get my stuff done fast.
To sum this up: this series of articles is not about bashing other editor, but to showing why I started Kephra in the first place. because most editors do the usual stuff like all the other do it too. to innovate is one of the most misused words by microsoft but innovation is needed in a lot of places and frankly i can't change all the bits in kommodo or notepad++ i would like. beside notepad is windows only and kommodo is not free as i can get really hands on the UI design. So there is a real need for Kephra. many are happy with the things there used too but but some who are picky about details and wand to tweak even small issues by changing the configs, may find kephra fitting.
uh, one thing i forgot. there was one menu more, that is currently disabled, because the AUI::Notebook can't react on mouse events. so it maybe will appear as a regular menu in the main documents menu. Its about a list of all open docs in a way you can look up their full file path. many editors waste a full menu on that but frankly i use that never and beside that most uses are already covered by the automatically generated menu on the AUI::Notebook.
Here's another thing that I don't remember actually having seen on an editor yet — or at least, on a free or cheap editor — I don't actually know if Kephra does: let the tool buttons and menu entries depend on the type of file.
It removes clutter if you don't show any menu entries that don't make sense on this type of file.
For example, if you have the Java compiler (javac) defined as a tool, it makes no sense to show it as an option for a Perl script. And vice versa: show perl only as a tool for Perl scripts and modules, but not for Java source files, or for HTML.
That implies making the context menus very dynamic, as they should be both dependent on file type, and be user configurable as well. This may be a bit of a technical challenge.
Re:Another idea on context, for menus and buttons
sir_lichtkind on 2009-12-10T13:10:09
yes its the next logical step. the technical basis for that is there and it doesn't sound that challenging to me. Now menu items deactivate (turn into a shadow) if the enable call say no (aka 0 aka '':) ) and this calls are checked before the menu popup. because on windows this event is fired on any menu popup of the main menu, i currently thinking about to change the enabling and toggle items if the content changing event was triggered. its not a too large change because currently the Kephra::Menu lib can do a lot of dynamic and flexible stuff. just hiding items is a nice idea i just have to test it on a small prototype but it doesnt make that much sense now, because there arent that much things that get disabled.
the other thing you wrote about are menus for special syntax modes. padre already does it and kephra will also have it after 0.5. we currently build some features that are pretty basic and urgently needed in Kephra. but after that i have planned to introduce syntax modes, that go beyong highlighting. its about what comment chars belong to that language and what tools and so on and then you will get such dynamic menu. its all already working in my head. you just have to download it and run the brain2perl.pl.:)
