On Wed, Oct 27, 2010 at 7:18 PM, Carsten Haitzler <[email protected]> wrote: > On Wed, 27 Oct 2010 21:21:30 -0200 Gustavo Sverzut Barbieri > <[email protected]> said: > >> 2010/10/27 Vinícius dos Santos Oliveira <[email protected]>: >> > Don't remove it, please. >> > There are bugs, but these features are needed by some people. >> > >> > Em 27 de outubro de 2010 19:58, Carsten Haitzler >> > <[email protected]>escreveu: >> > >> >> On Wed, 27 Oct 2010 13:35:31 -0300 Vinícius dos Santos Oliveira >> >> <[email protected]> said: >> >> >> >> i so feel like killing off systray again. :) fyi shelf autohide is full of >> >> holes and problems. it was not implemented solidly to begin with. i'm >> >> tempted >> >> to kill it off as a feature just because i couldnt be bothered fixing it >> >> all >> >> up. and that reminds me - edge bindings have problems of their own too... >> >> The bug there is that the shelf does not get the mouse-out event (as >> event goes to the child/systray window, then goes to its menu, then >> off shelf), thus the auto-hide is not triggered. > > oh there are other usability issue s- like the fact that it was designed to > work on mouse in and out on the shelf - this means some section always has to > be visible. if u dont have a compositor and have shaped windows - like an > invisible shelf, you will never get a mouse in as the edge of the shelf is > never actually visible and able to get that enter event. i am sure i grumbled > about this before and people who want the feature never fixed it. it should > if > ANYTHING be tied to edgebindings (which is why i mentioned it above). and this > is why edges are not so easily made "generally bindable" as we need them for > all sorts of special cases (desktop flip etc.). before desktopflip was the > only > user - but shelf autohide/show should have too - but then it got turned into a > general thing and lots of problems appeared - like keeping edge bindings even > if they ONLY binding was to flip desktops and u had a 1x1 virtual desktop > setup > (thus making window borders inaccessible at the edge of the screen even there > is no need for that screen edge), same with desktop flip and multiple screens > (edge flip basically can't work as long as u have 2 screens with independant > desktops to flip - so it should get auto turned off)... and much more. there's > a lot of specialised if cases based on usage and behavior we just cant do > nicely with generic bindings. > > if someone doesn't go fix all these nasty cases up - i will guarantee you, i > will eventually, when i get around to it, kill edge bindings, kill shelf > autohide and restore the old simple stuff e used to have that was actually > correct and worked for all cases. it turned off the invisible window catchers > when there was nothing left to catch at an edge and thus made that edge usable > again for grabbing window borders or other things. if you want an e17 ever > released you will have to accept the fact that either things are fixed - or > they are killed. as i disagree with the whole way both of the above have been > designed and implemented to begin with (as the whole implementation concepts > are wrong), i will just kill. so it stays broken for now until i get around to > that... or someone fixes this all up with a LOT of extra code to work right.
ah man, that would be :-( i hope this is fixed properly. edge bindings and autohide are somewhat important to my setup, as i like to have maximum screen real estate at _all_ times, until i need something; that and i have a passionate hatred of taskbars :-). i especially liked corner bindings back in the compiz days to trigger the scale plugin, allowing me to rapidly switch between many windows. however, i understand the need to cut that-which-does-not-work-right. in terms of usability though, i think it does far more _for_ than against (real estate). could a specific/permanent object receive the events, then delegate out to interested/appropriate recipients? this way the binding never changes. pardon my ignorance, i'm from the python/javascript/DOM/dynamic lang sphere... there are similar situations that occur when handling events (in particular drag) in JS, and the solution is to use a short-lived, empty element spanning the entire screen, to guarantee the mouse never leaves. C Anthony ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
