ok. so i'm stuffing effort into elm menu and dark theme... elm menu needs love. the theme end i think needs a re-do. it will have to break. here is why:
1. check and radioitems are not supported in menus and frankly they should NOT consume icon spots. icons are separate to these indicators. so check and radio indicators need to be added/rolled in. 2. if a menu has NO submenus.... NO space for an arrow should be allocated in any menu item. if there is one submenu.. then space need allocation in ALL items (so everything aligns). same for icon slot, check/radio indicator slot and label slot. this ensures all items aligns content nicely. e17 does this in code via a box and padding objects, but either way to make this happen would break the current theme setup anyway where items have labels shuffle all over the place etc. OR forcibly always allocate space for icons even if none exist in the entire menu. 3. looking at hover usage... i think this is really just abusing the hover obj for something it was not meant to do. menus should really do their own placement by hand for submenus etc. 4. mainmenu bar needs some love. things like the main menu item should stay active while a submenu is up, (or at least have a signal emitted to let it know its child menu is still up, or not), and same for every menu with a submenu attached to it. 5. menu has some really bad habits when space is at a premium and in some cases resulting in infinite loops. solutions are to scroll menus ala e17 or to scroll within the menu obj/box itself with some scroll arrows at the top/bottom... ? (mouseover them to scroll that way? click them to scroll that way?) 6. other bad habits are not having timeouts on mouse movement so when your mouse diagonally moves from the submenu item to the submenu that opened and goes OVER another item in the parent menu along the way, your submenu goes down. bad! e17 solves this with a timeout on moves waiting for moves to stop for a period of time before opening a submenu if one is already up). 7. no key controls like e17 menus have. 8. given the way styles are done, we cant have a different style for the bg/base/hovers like we can with items... so effectively elm style features are broken with elm menus. 8. so in general you can probably guess that i pretty much want to bring elm menus up to on-part with e17 menu functionality/behavior. e's menus may not be the most advanced and amazing menus on the planet, but they are light years ahead of elm's menus and actually usable. :) btw - api is fine - no plan to break it, just extend it. in general i feel the menu code really needs some overhauling. maybe a rewrite even. yes - i'd want to keep the dbus menu support. i'm not looking at that right now mostly because i dont have an environment with it enabled. so my questions are: 1. is anyone using menus in a way that a theme break would hurt them? 2. anyone got comments about elm menus in general in addition to the above to fix them? disagree with them? 3. if i go ahead and do this... i need to decide how to do it. i can do it e17's way and manually control a box to ensure alignment etc. and make it easier on the theme, but this does limit theme power a bit. or should i make the theme more complex and harder to add menu features to in the name of theme power to do more? (then theme cant place icon where it likes for example). i'm mulling this over. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
