Re: [E-devel] E submenu placement
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 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)[EMAIL PROTECTED] $BMg9%B?(B Tokyo, Japan ($BEl5~(B $BF|K\(B) -- 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
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
Re: [E-devel] E submenu placement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE1MIaMkyGM64RGpERAk5pAKC9x0xwViz5Z4teQTkEnDk9NVKRuwCeNWkk V2aK87SXHLXmZ8j5zcRw7h0= =PUrP -END PGP SIGNATURE- - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
Well, many people like/dislike such menu behaviour. So, in order to satisfy all around it would be greate to have this functionality as an option. On Sat, Aug 05, 2006 at 06:06:51PM +0200, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE1MIaMkyGM64RGpERAk5pAKC9x0xwViz5Z4teQTkEnDk9NVKRuwCeNWkk V2aK87SXHLXmZ8j5zcRw7h0= =PUrP -END PGP SIGNATURE- - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Aleksej Struk Master Degree Student Free University of Bozen-Bolzano Faculty of Computer Science phone: +39-0471-061749 cell phone: +39-3204627049 +370-61278908 [EMAIL PROTECTED] [EMAIL PROTECTED] - http://astruk.googlepages.com/home - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
On 8/5/06, Koen Kooi [EMAIL PROTECTED] wrote: Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. Offscreen menus can slide in if you push against the offscreen edge. Turning this into an option for E would be a good idea. -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
Hisham Mardam Bey wrote: On 8/5/06, Koen Kooi [EMAIL PROTECTED] wrote: Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. Offscreen menus can slide in if you push against the offscreen edge. Turning this into an option for E would be a good idea. Yeah, thanks for showing me that on irc. I hadn't seen that behavior in so long I didn't discover it again on my own. It would be handy if the off screen menu had some visual indication of the possible slide behavior. Maybe a grayed edge, or some little arrow indications, or such. Does that sound interesting to anyone? -- 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hisham Mardam Bey schreef: On 8/5/06, Koen Kooi [EMAIL PROTECTED] wrote: Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. Offscreen menus can slide in if you push against the offscreen edge. That virtually impossible to do with a touchscreen, since you can't 'move' the pointer without generating a button-down event[1]. An option for this would be great! regards, Koen [1] not to mention the amount of jitter of this touchscreen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE1Mh3MkyGM64RGpERAqJ7AJwJ3OFmawEh6Fb+QKaDZAcrCgXz9wCggjcH g9Iu16R4Vcg0fYSnIbo+Rmk= =mvXI -END PGP SIGNATURE- - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. hehe, almost the first thing I noticed on my new e17 build also. It sounds like we might make it an option, along with the slide behavior. -- 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hisham Mardam Bey schreef: On 8/5/06, Koen Kooi [EMAIL PROTECTED] wrote: Kevin Brosius schreef: 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. You are a hero! The whole 'menus go offscreen' thing has been annoying me since I installed e17 on my 800x600 psion netbookpro last week. Offscreen menus can slide in if you push against the offscreen edge. That virtually impossible to do with a touchscreen, since you can't 'move' the pointer without generating a button-down event[1]. An option for this would be great! regards, Koen [1] not to mention the amount of jitter of this touchscreen Koen, That's a good reason :) You might find it helpful to change some of the menu scroll settings. It seems to me that under (left mouse menu) | configuration | configuration panel | Menu settings, advanced, the setting 'Autoscroll Margin' determines how far from the screen edge the menu will be scrolled, and the 'Autoscroll Cursor Margin' controls the hot zone for scrolling. Making your cursor margin setting 10 or 15 pixels should help. -- 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E submenu placement
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). 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). 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: |screen edge [menu] | []---[sub] | [][ ] | [ [sub2]-[ ] | [ [] [ ] | [] | 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. ... 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 (東京 日本) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
