On Fri, 21 Oct 2005 11:34:47 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> When I made my E16 theme, I hacked the window menu for greater > usability, and it looks like I will have to do the same when I port my > theme to E17. In an effort to avoid menu hacking in a theme, I will go > over those changes and their reasons now. > > First of all is the position of the Close and Kill items. With my E16 > theme I found myself accidentally selecting Close, as the menu > starts with Close already under the mouse pointer. Traditionally, the > menu item that exits out of the application is at the bottom of the > menu, for a good reason. For languages that scan from top to bottom, > it makes sense that the last item you will ever select is the last item > on the list. To avoid accidentally exiting out of something that may > require some non trivial amount of work to setup again (things like, > you are half way through a big HTML form in your browser) it makes > sense to not make application exiting too easy. > > A window manager does not know if closing this window closes the > application, or if closing this window can be easily reversed by the > application just opening it again. For these reasons, I think that the > Close item on the E17 window menu should be at the bottom of the menu, > and not at the top. The same argument applies to the Kill button, but > since it WILL kill the application, and possibly in an unfriendly > manner, it is more dangerous, and should be slightly harder to do. Put > Kill at the very bottom, maybe add a "Are you sure?" dialog. i agree this is probably a good idea - its a trivial re-ordering in the menu generation code for the border menu :) the "are you sure" is possible - though a bit more code :) > My second usability menu hack is mostly due to my small resolution > monitor. But I think it is a good idea anyway. When a window > takes up the entire screen, either maximised or fullscreen, or when all > of the root window is completely covered by widows, there is no root > window exposed for you to click on and pop up the E menus. This makes > the user switch desktops in a desperate search for some exposed root > window to click on. I know that there is a key binding for that > purpose, but it is not obvious, and not everybody has that key on their > keyboards. you don't have ctrl, alt and an m key? you do know there is MORE than 1 binding to do this? :) > My solution is to include the desktop menus in the window menu, which > is always just a click away. Unless you have no visible borders of > course. that's the idea of the start module... :) > Having recently cloned the start module to give me a starting point for > my emu module, I suspect that the above changes are quite trivial, and > I would be happy to do them myself and commit. As always though, I > will discuss it here first. ok- putting the main menu in the border menu is non-trivial as then we need to keep track of and free all menus AND submenus of this main menu. in future we just need to improve maximize to not go over modules like the pager, ibar etc. and make smart maximisation the default. then ALLthese things are ALWAYS accessible - INCLUDINg the "root menu?" -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
