On Mon, 12 Aug 2013 11:39:55 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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. I'm still deciding if Elementary is something I actually want to use. I tried it out on a previous project, and rejected it in favour of raw Edje and Lua for that project. I've been trying it out for a new project, and still not liking it. One of my biggest problems with it is that everything is just too huge, even with finger size set to minimum and those other things people have suggested I should do. I designed my perfect widget system long ago (in Java, before I gave up on Java), and Elementary is not a good match for it. So my choice is basically to write a new Elementary theme from scratch, or implement my perfect widget system on top of Edje + Eo + Lua. Neither would be an easy job, I'm still undecided. You are correct, Elementary menus suck in other ways, and needs a redo. E17 menus suck a lot less, so might be a good idea to reuse them, then factor out the common stuff to share code. I'll wait to see what you come up with, suckage might be small enough to help me decide to stick with Elementary. So my answers are - 1. Yes using it, but not in earnest yet, so breakage is OK by me. 2. I'm all for stripping out excess space so that Elementary stuff is not so fucking HUUUUGE. So some of your ideas seem good for that. Check and radio items are a must have. Breaking those bad habits is good. Key shortcuts is great, including displaying them. 3. As I said above, reuse E17 code, factor it out, then we can improve that common code to get better menus for all. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
