On Sun, 2009-08-30 at 10:01 -0500, Nick Hughart wrote: > On Sun, 30 Aug 2009 15:28:11 +0300 > Viktor Kojouharov <vkojouha...@gmail.com> wrote: > > > On Sat, 2009-08-29 at 18:56 -0500, Nick Hughart wrote: > > > So the edge bindings have once again ticked me off. So much so that > > > I've made the attached patch to correct it's flaws. I tried to keep > > > as much of the mechanisms the same even though I don't exactly like > > > how it's done right now. > > > > > > Anyway, the patch fixes a couple of things. > > > > > > First it will hide any of the edge windows if that edge is not being > > > used. It is pointless to have the entire 1px border of the screen > > > unusable when I have no edge bindings. > > > > You need to do a bit more than just monitor the bindings. The shelves > > also use the edge events to show/hide themselves. With your patch, if > > a shelf is set to auto-hide, it will never show if that edge does not > > have a binding as well. I am personally against this bit of patch > > (and I was against it before), as the edges provide more than just > > bindings. They also provide events that can (and are) used regardless > > of whether a binding for that edge exists or not. I guess one > > solution would be for all users of these events to instead provide > > actions, which can be user-bound to a specific edge, but I am not > > sure how well that would work, since it would require user action, > > which might not be desirable. The later bit of the patch also fixes > > your gripe a bit, since that 1px of screen realestate becomes usable > > for certain apps (imho all that really need the edges are fullscreen > > games anyway). > > Anything with an edge scroll which could be implemented in more then > just a game. An app itself may also have slide out panels > that are activated by an edge when fullscreen. Regardless, it's not > like people don't play games in Linux these days so this is or will be > an annoyance for more people then just me. Exactly, that's why I am in favor of the part of the patch that moves the edge windows on a lower layer.
> > Having some action fire when you hit an edge without a binding in the > list is just like having random key or mouse bindings without having > one in the list. This is generally unaccepted in E and I don't see why > edge bindings would be any different. If you want to do something on > the edge, then you need to provide a binding in the list. We are not talking about bindings though. Edge bindings are just a "bonus" for having edge event windows. I'm talking about events, just like there are mouse and key events. And users are more than accustomed to having things activate on mouse and key events. > > I did test the shelf autohide and it appeared to work just fine with my > patch so apparently I didn't break that. As long as the shelf uses > e_bindings_edge_add/del it will work just fine. It doesn't now, it uses events. That's why its not working with the patch you provided. If it provides bindable actions, then it will work. I'm not sure if its feasible though. We can have multiple shelves on a single edge, and you can only have one action per binding. > > And why would adding bindings require user action? Many modules add > default keybindings these days and doing so for edge bindings should > not be a big deal. Might as well have all modules go through the same > binding mechanism or users will be running around changing settings all > over the place instead of having just 1 place to modify them. > > And yes, the lower part of the patch does help with my particular > situation. Even so, someone may have a case where a corner activation > is OK, but they still want to use their edges. In this case they would > have to have the event windows above fullscreen windows, but they still > need the edges free. Note that this is hypothetical, but I could see > something like a fullscreen drawing app with pop out panels activated > by the edges. An app can only get access to that region of the screen, if there are no borders on the window anyway. And probably the most uniform way to do that is to make it fullscreen. So the lower part of the patch will solve that, without having to show/hide windows all the time. > > > > > > > > > Second it fixes the behavior of the fullscreen option. Previously > > > the edges were set above all windows, even fullscreen. The only > > > difference with the option set was that events would be ignored, > > > but the edge window was still in the way stealing events. It is > > > much better to actually layer things properly so that when a > > > fullscreen app is active, the edge windows are layered below it and > > > thus do not get in the way at all and don't even have to ignore the > > > events because they never happen. > > > > The layers look good. Though I wonder whether setting layers to be > > LAYER > > - 1 would be better. So for instance, when the fullscreen option is > > not turned on, the edge windows would be 1 layer below the fullscreen > > windows. Not sure how window stacking works, so maybe your solution > > works just as well. > > Well layer 200 is special. Shelves that are above all and fullscreen > windows are on layer 200. I'm not sure why fullscreen windows are on > the same layer as above all shelves, but apparently it works out. The > 250 is above the fullscreen layer and thus above everything existing > best I can tell. Not sure what setting the layer to -1 will do > exactly unless it just sets it to the highest layer possible. > > > > > > > > > Patch attached. I would just commit it, but I know I was met with > > > resistance for some reason the last time I brought these issues up. > > > ------------------------------------------------------------------------------ > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > 2008 30-Day trial. Simplify your report design, integration and > > > deployment - and focus on what you do best, core application > > > coding. Discover what's new with Crystal Reports now. > > > http://p.sf.net/sfu/bobj-july > > > _______________________________________________ enlightenment-devel > > > mailing list enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
