[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] E submenu placement
"Carsten Haitzler (The Rasterman)" wrote:
> On Sat, 05 Aug 2006 12:01:01 -0400 Kevin Brosius <firstname.lastname@example.org> 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
there is still a comment in the code that the menu-reposition function
may be inefficient for large menus.
> 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.
> 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.
> |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...)
> 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?)
I suspect that making menus require a click would make noisy touch
screens harder to use, rather than easier though. Just my opinion
> ... 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@example.com
> Tokyo, Japan ($BEl5~(B $BF|K\(B)