Re: [E-devel] Module Popup Policy
On Thu, 2007-02-22 at 19:15 +0100, Brian 'morlenxus' Miculcy wrote: Hi all, there was a small discussion on the irc about the module popup policy. Currently each module has his own policy: - mixer opens the popup on click - net module opens on mouse over, if you click the popup stays open - weather opens on mouse over, no click event So i think there should be a standard for the module popup. Here is my idea: Mouse over: The mouse over popup is enabled by default. You can disable it using an option in the module configuration dialog. Click: The click locks the popup. This means, if you leave the module icon area, the popup isn't closed. If you want to unlock the popup, you need to click once again. A nice feedback to the user would be a little lock icon. If the mouse over popup is disabled, a click would open the popup and locks it. To close the popup simply click. The mouse over gives you a quick view at the popup without much user interaction. The locking mode allows you to have a popup with useful informations open, while running some other processes. Example: A memory module shows in the popup a list with the top memory eating applications (i guess firefox would be at the first position). The list is updated every second. If you now lock the popup you would be able to kill the applications with some xterm commands - while still having the list open and show you informations. Without the locking mode you would need to hover the module icon again and again after running a command, just to see if there has been something changed. I guess the user would open another xterm and run `top` there, so the module popup information would be a nice eyecatcher, but doesn't really help. Another example would be a calendar module which shows a month view in the popup. Sometimes you just want to know a day in the next week, sometimes you want to write some email while having the month view on screen. Imho it's useful. :) Comments? I _love_ it :)) -- Build a person a fire, and they may be warm for a day. Set that person on fire, and they will be warm for the rest of their life. GnuPG Public Key ID 1024D/203C7431. Public Key Available From http://keyserv.nic-se.se:11371/#extract signature.asc Description: This is a digitally signed message part - 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] Module Popup Policy
Yes, thats true. So a mouse over wouldn't be useful, but i would use the click policy here. Currently the module locks keyboard and mouse input to the popup, so you wouldn't be able to do something other. I would remove these locks, to that the click opens the popup, but you are able to have it open while doing something other. So, mouse over popup no, but click popup would have the same behavior as i descripted before. Greets, Brian 'morlenxus' Miculcy On Thu, Feb 22, 2007 at 07:34:24PM +0100, Simon TRENY wrote: In my opinion, there is a difference between the popup of the mixer module and the popup of the net/weather module: in mixer, the popup is used to change the volume, there are control-widgets inside it, while in net/weather, the popup is only used to display infos (I've never tested the weather module though, but I think that how it works). And this difference explains the different behaviors I think: you don't want to see the volume bar each time you enter the mixer's icon, because seeing the bar is useless. Everytime you might want to see the volume bar, is because you want to change the volume, and then you need to lock the popup anyway. And actually, it would annoy me a bit to have the mixer's popup show each time I move the mouse over it. Regards, Simon TRENY MoOm On Thu, 22 Feb 2007 19:15:28 +0100, Brian 'morlenxus' Miculcy [EMAIL PROTECTED] wrote : Hi all, there was a small discussion on the irc about the module popup policy. Currently each module has his own policy: - mixer opens the popup on click - net module opens on mouse over, if you click the popup stays open - weather opens on mouse over, no click event So i think there should be a standard for the module popup. Here is my idea: Mouse over: The mouse over popup is enabled by default. You can disable it using an option in the module configuration dialog. Click: The click locks the popup. This means, if you leave the module icon area, the popup isn't closed. If you want to unlock the popup, you need to click once again. A nice feedback to the user would be a little lock icon. If the mouse over popup is disabled, a click would open the popup and locks it. To close the popup simply click. The mouse over gives you a quick view at the popup without much user interaction. The locking mode allows you to have a popup with useful informations open, while running some other processes. Example: A memory module shows in the popup a list with the top memory eating applications (i guess firefox would be at the first position). The list is updated every second. If you now lock the popup you would be able to kill the applications with some xterm commands - while still having the list open and show you informations. Without the locking mode you would need to hover the module icon again and again after running a command, just to see if there has been something changed. I guess the user would open another xterm and run `top` there, so the module popup information would be a nice eyecatcher, but doesn't really help. Another example would be a calendar module which shows a month view in the popup. Sometimes you just want to know a day in the next week, sometimes you want to write some email while having the month view on screen. Imho it's useful. :) Comments? Greets, Brian 'morlenxus' Miculcy - 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 - 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] Module Popup Policy
On Friday, 23 February 2007, at 02:02:20 (+0100), Brian 'morlenxus' Miculcy wrote: Yes, thats true. So a mouse over wouldn't be useful, but i would use the click policy here. Currently the module locks keyboard and mouse input to the popup, so you wouldn't be able to do something other. I would remove these locks, to that the click opens the popup, but you are able to have it open while doing something other. So, mouse over popup no, but click popup would have the same behavior as i descripted before. Please stop this ridiculous thread. Different modules can, should, and do have different mouse bindings. Not everything needs to be standardized. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- 90% of a woman's pheromones come out the top of her head. That's why women are shorter: so that men will fall in love when they hug them. -- Phoebe Buffay (Lisa Kudrow), Friends - 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
