On Sun, 06 Aug 2006 16:11:07 -0400 Kevin Brosius <[EMAIL PROTECTED]> babbled:
> "Carsten Haitzler (The Rasterman)" wrote: > > > > > > On Sat, 05 Aug 2006 12:01:01 -0400 Kevin Brosius <[EMAIL PROTECTED]> > > babbled: > > > > > So, who is working on e menus at the moment? Am I stepping on any toes > > > if I commit stuff like this? > > > > > > The attached patch prevents submenus from being drawn off the right side > > > of the screen. > > > > > > Are there bigger plans for menu layout adjustment? I see that placement > > > also needs to take in to account the bottom of the screen. That isn't > > > fixed yet. > > > > well other than what codewarrier said (you can drag to the edge of the > > screen and scroll - e17's menu code can handle massive menus - well beyond > > the size gtk or qt can due to just letting you scroll them). > > > > I'll have to try this... Does it ever stop scrolling? ;) I do notice yes - move mouse away from the edge, or when all of the menu is displayed that was off screen :) > there is still a comment in the code that the menu-reposition function > may be inefficient for large menus. we aren't there yet :) (the problem being it just loops thru all active menus as opposed to walking the menu tree - but really - that comment is being very picky - it's not an important thing atm.) > > yes an inidactor might be nice - in practical terms that probably would > > need to be yet another window with a canvas (maybe an e_popup) placed on > > the edges of the screen where you are able to scroll and then shown when > > needed (also emit a signal so it knows it was shown and can start animating > > or something). > > > > Yes, I was thinking about something like that. Placing the menu off > screen with no indication means the user has to learn about the > scrolling by luck or reading the docs. yup - indicator i think should be done regardless and in addition to mouse to edge of screen, a mouse down on the inidicator starts a scroll (mouse up stops). > > but your patch imho is a little incomplete. the submenu arrow will point > > the wrong way. you need a way of now having the theme have 2 modes (open to > > the left or open to the right) and you need to select this when the first > > parent menu opens. your patch also will have problems: > > > > Hmm, well, I think I could make an argument that the arrow indicates a > submenu exists, but doesn't have to point the direction of actual > expose. For cases where the menu would obviously appear off screen, I > don't think the user will be surprised if we place it in a better > location that is visible. but arrows point in a DIRECTION - they have a symbolic meaning already to people - they are visually looking to where the menu points to see something - but then it appears somewhere else - it's just bad (tm) :) > > |screen edge > > [menu] | > > [ ]--->[sub] | > > [ ] [ ] | > > [ [sub2]<-[ ] | > > [ [ ] [ ] | > > [ ] | > > > > Yes, definitely. This was just an initial stub at different layout. > Are you committed to a policy of the menus not overlapping? I was > thinking it might be better to do some percentage of overlap for cases > like this (if we allow a different menu display policy at all...) well it'd be nice if they didn't overlap - it makes them less readable/usable. in this case unless u go in only 1 direction, you can't control the overlap. note - we can do other things - like if a menu is off screen begin a very slow animated scroll when the inidactor appears sliding the menu in slowly to hint that "there is more down here" showing some of it, and then slowing down and stopping once N pixels are exposed - and hopefully this together with and indicator will make this much more obvious. this is just how to improve what we have right now without changing layout policy though - so this is a separate topic. > > and yes - touchscreen has problems - IF you "tap" then "tap" again. if you > > "press and drag" style menu (you dont have to release the mouse - or raise > > the pen) then it works just fine btw :) but yes - this does limit your > > ability to interact with menus a bit. but as per above we have a few > > problems. > > > > 1. arrow indicator is now wrong > > 2. menus will overlap back and forth > > 3. there are menu occasions where the menu code has no idea how big a > > submenu will be before it is shown (as the contents are generated when it > > is shown to speed up initial menu popup), so you can't know in advance what > > arrow to display (thus you will need a way of flipping submenu arrow > > display on the fly) 4.we can probably make the flip back.forth usable if we > > allow a tap/click on the submenu parent item will TOGGLE the display of the > > submenu as opposed to just always display it if it isn't displayed. > > Yes, 3 will be an issue... > 4 - hmm, I can't quite picture that behavior. Would that require a menu > mode change, such that tap shows a submenu, and only that submenu (so > submenus only show on click events, rather than on mouse over?) right now - do this. tap the mouse (down and up quickly) then move the mouse to browse. if you tap or just mouse down on any submenu menu item (the menu item with an arrow) NOTHING happens because the menu is already visible due to mouse over - it doesnt appear or dissapear. we simply need to now make a tap on a submenu item toggle the submenu visibility. > I suspect that making menus require a click would make noisy touch > screens harder to use, rather than easier though. Just my opinion > there. > > > > > > ... anyway - my point in this is... i applaud your efforts to work on this > > - but i think you need to think more widely on the implications of the work > > and all the fine details/touches and solve them too :) > > > > (nb - i think we can also solve the touchscreen problem and not even make > > menus open to the left - if we allow you to CLICK on the "you can scroll > > here" indicator/arrow and click and hold begins a scroll in that direction > > - the only problem is keeping the popups above the menu then :) > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > > 裸好多 > > Tokyo, Japan (東京 日本) > > -- > Kevin > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
