On Wed, 27 Oct 2010 20:18:27 -0500 C Anthony Risinger <[email protected]> said:
> > 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 :-( indeed - sorry, but when it comes to a release - either code works right or is removed/disabled/shuffled away somewhere that is hard to get to. :) > 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 :-). to fix properly needs a rewrite of both systems. edge bindings should not work as they do now - you should register at runtime from some bit of code "interest" in an event at an edge (edge events always happen after a short timeout, then hide the event catcher window and "poll" the mouse until it moves away from the edge again - then restore the catcher). only edges that have registered "interests" should have such catchers. so as such desktop flip shouldnt be an action in edge bindings - it should simply be the virtual desktop handler registering for edge events *IF* you have 1 screen AND u have a virtual desktop to flip to in that direction at the time AND if the feature is enabled in the virtual desktop section. if you want other generic events too - this is a binding registering interest in and edge like the vd system and getting its callback when you go there. only edges that have bindings should register interest, and then ONLY if that edge of the screen "makes sense". if i have 2 screens (one on the left, one on the right" the screen "edges" between the 2 screens are not useful and edge bindings should refuse to capture anything there as the mouse doesnt stop at the edge - it will slide off to the next screen. in addition shelf autoshow/autohide... should be done with these invisible event windows too but make sure they are above edge binding windows. in fact.. edge bindings should ovver "sub regions" of the edge to be bound and offer you to register interest for the whole edge or just a sub range on an edge. shelf would do this and ... then get its callback called - thus showing the shelf then. shelf should probably then poll the mouse to check when it exits the shelf region. the region should be the popped up shelf + some reasonable padding of pixels (20, 40, 60? configurable value - probably depending on resolution, dpi etc.). shelf and edge bindings need to co-operate so that while mouse is in the region of a shelf on the same screen, that it needs to detect a mouse just hoverign near the screen edge then "accidentally getting to the edge" vs me moving my mouse in from far away to an edge to do a flip - i.e. if mouse is in shelf region for more than 0.3 seconds for example then edge flip near the shelf wont work anymore until i move away from the shelf (autohide or not), then come back and quickly slide my mouse to the edge (implying i want to actually slide across that screen edge). anyway.. the above is a start at fixing it. > 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. see above :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
