[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 <cobra@compuserve.com> 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
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)    raster@rasterman.com
> 裸好多
> Tokyo, Japan (東京 日本)

-- 
Kevin