On Mon, 2009-08-31 at 22:23 -0500, Nick Hughart wrote: > On Mon, 31 Aug 2009 09:14:13 +0300 > Viktor Kojouharov <vkojouha...@gmail.com> wrote: > > > On Sun, 2009-08-30 at 18:56 -0500, Nick Hughart wrote: > > > On Mon, 31 Aug 2009 01:08:36 +0300 > > > Viktor Kojouharov <vkojouha...@gmail.com> wrote: > > > > > > > On Sun, 2009-08-30 at 11:17 -0500, Nick Hughart wrote: > > > > > On Sun, 30 Aug 2009 18:28:04 +0300 > > > > > Viktor Kojouharov <vkojouha...@gmail.com> wrote: > > > > > > > > > > > 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. > > > > > > > > > > All key and mouse events do nothing unless bound to some action. > > > > > Edge bindings should be the same. If the edge windows weren't > > > > > in the way they could probably just do the same thing, but they > > > > > cause issues so they should be handled specially. > > > > > > > > Hmm, then we must fix quite a lot of E, since there are quite a > > > > lot of seemingly random actions that get called by events which > > > > are not bound by actions. Right-clicking on the title bar seems > > > > to be one of them. > > > > > > Ok, fine, there are some static bindings that can't be changed. > > > These could probably be changed without a whole lot of effort if > > > the titlebar became a context if someone had the motivation. So > > > far though, this hasn't pissed anyone off enough to be fixed. > > > > > > Also the titlebar bindings don't affect anyone unless they want to > > > use them, the edge windows effect everyone even when they don't > > > want them. This is what I'm trying to change. If the user really > > > doesn't want edge bindings they shouldn't be in the way. > > > > > > If you really want to keep these around for events, then another > > > wrapper should be made that will be used to show the edge and > > > register the event handler. And similarly one to unregister and > > > hide the edge. But then one could just as easily just add a binding > > > instead. There is already a 'Show the Shelf' action that can be > > > used for shelf purposes. > > > > > > I know about that action. And I do think that actions are better than > > constant events. But like I said before, I am not sure actions will > > work perfectly for showing shelves. Lets say we have 3 shelves: foo, > > bar and baz. Two of these are on the bottom of the screen, and one is > > on the top. How are you going to make 1 binding show shelves "foo" > > and "bar"? > > Yes, shelves on the same edge are going to be a problem when using > bindings as the edge binding has no concept of size. But I have some > new thoughts on this after our conversation. > > Get rid of the shelf's dependency on the edge bindings/events. It > already handles click to show on it's own so I see no reason why it > can't easily handle a mouse in. Using the edge bindings/events may seem > like the clean way to do it, but I think in this case it just > complicates things. Either way the shelf is listening for an event, > just change which event. I guess the only time this gets complicated > is when the shelf is below all, but that can be dealt with. Below all > is about the only case where the edge bindings have some usefulness > since the shelf isn't it's own window in this case. >
A long time ago, I tried to do that, but a lot of people were against this, raster included. IIRC, popular reasons were that it wasn't clean, it was flaky, to it just sucked. And they had their reasons, since showing a hidden shelf was quite buggy. That, and you'd need two sets of logics to cover shelves that are on the background edje and those that reside in a separate window (since those on the background edge would need a new set of code). I'm not sure if popular opinion has changes since then :) By the end of the week I will experiment with actions for showing the shelves, but if you have time before that, please do so. My idea is that "Show the shelve" should be special in the context of edge bindings (just like other actions have special meanings in other binding contexts), An pointer on an edge will tell all the shelves on that edge to show, and those that are set to show on mouse move will do so. If the user selects click-to-show, the edge action will be deleted and if there are no mode bindings, the edge itself will be hidden (if nothing else uses pure events, we have to grep for that). If it turns out that nothing else uses these events, I'm not sure whether we should delete them entirely. We need some opinions on that one, but I guess it wouldn't hurt to leave them be, as long as it is understood that an event window might not be present under certain circumstances. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Uh, I said it IS working. Besides, with these dumb event > > > > > windows in the way, you prohibit click to show from working on > > > > > the very edge which is incredibly annoying, especially when the > > > > > theme doesn't have more then 1px showing. > > > > > > > > click to show? > > > > > > Have you looked in the shelf settings within the past 5 years? > > > There is a 'Show on mouse click' option for unhiding the shelf. If > > > someone chooses this option, they will expect to just throw their > > > cursor to edge their shelf is on and click. With these event > > > windows always visible, the shelf won't come up and they'll get > > > pissed. Then we'll get a bug report, a complaining user, or they > > > will just go back to Gnome/KDE. > > > > There were no shelves 5 years ago. Or am I to assume you know every > > last of E17's settings? But click to show will have to be made to > > work with click events from the edge windows, or you will still get > > bug reports, and angry users switching back to Gnome/KDE. Having a > > single binding for the underlying edge will make it show, thus > > blocking clicks. And in the spirit of your previous ideas, > > click-to-show will have to become an action. But currently there are > > no edge contexts in the mouse bindings dialog, and there are no > > clicks in the edge bindings. > > > > Ok ok, it was like 3 years ago when shelves were added and probably not > soon after the show on click option was added. Anyway, I don't think > using a click on the edge window is the right way to go here. The > problem is that the shelf when hidden still has a few pixels visible. > So if you add this code to the edge bindings to show the shelf on > click, you'll still need the code in the shelf if the user clicks > on the few pixels visible outside the edge window. I think the better > way to go is to get the edge out of the way when the user wants click > to show. > > Going to our IRC conversation we should do something like the > following (note that when I say edge I mean an edge or corner): > > Hide all edges by default. > > If a binding is added for an edge/corner, show that edge so the binding > will work. The user will then have control over that edge being shown > or not by simply adding a binding. > > Provide a wrapper function that modules can use to show/hide edges that > they'd like to receive events from. I think this will give you what > you want even though I don't think it will be used often if at all. I > don't think the user really needs control over this, the modules using > this functionality should provide their own means of configuration. > Like the shelf currently, they will have special needs like only dealing > with the event in certain positions along the edge. Another possibility is to add some special event action to the edge, which will not be shown in the gui. not sure which is cleaner, probably the wrapper function though. > > Could we maybe do something a bit different and allow multiple event > windows on a single edge that don't cover the entire edge? The module > would use a function where they could define the span they want the > edge to be in and provide a set of callbacks that should fire when the > mouse enters, exits, or moves. This could be used instead of my > suggestion above and would provide a more powerful mechanism that > modules can use, whilst keeping the simpler edge binding mechanism for > users. Biggest issue would be dealing with conflicts as placing the > windows and firing callbacks would be fairly trivial. if the event windows cannot pass events to other windows below them (i think they can't), this will turn rather ugly. you're going to be constantly dividing the screen into new windows, resizing old ones to fit, and delegating events across multiple windows. But if you think there might be uses for this, and if you have time to experiment, try it out. > > My main goal is to make the edge bindings a bit more dynamic instead of > the static way they are now. Give them a bit more flexibility which > should hopefully make them more useful for more applications and to > give users who don't require their functionality a way to get rid of it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > No it won't. It will move all the edges below the fullscreen > > > > > window and thus you cannot activate the corners. So the below > > > > > fix will not help this person. We could make this setting per > > > > > edge, but I think that just complicates things for the user. > > > > > > > > I'm confused here. You want the corner events to work, but not the > > > > edge events? > > > > > > This was just an example, read what I said again. My point was that > > > someone may want the edge triggers to be above fullscreen windows, > > > but they may need the edges for other things. So they would setup > > > the corners with actions and then they could use the edges without > > > interruption. As it stands currently, they can't do that and that > > > makes edge bindings useless to anyone in this situation. > > > > A bit of an edge case, but true non the less. Especially since corner > > actions are used a lot more than edge ones. > > Yes I agree is probably a rare case, but if gaming keeps gaining ground > on Linux like it has, it may not be so rare for someone to want a quick > way to check the weather while in a game by hitting a corner to popup > their gadgets :D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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
