On Tue, 01 Sep 2009 12:37:21 +0300 Viktor Kojouharov <vkojouha...@gmail.com> wrote:
> 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 :) Well dealing with a hidden shelf on the background would just require listening to edge events on the background instead of the shelf window and only responding to mouse moves within the shelf's visible space. But yes, this would be two separate pieces of logic. > > 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. > Well if we require the use of a wrapper function to register the event callback, then we could use that to determine if the edge is in use or not. Probably want to add a ref counter to the edges to make this simpler. We might also want to think of a better way to show/hide the edges as doing a huge case statement as I did in the add/del functions seems dirty. Maybe put all the edge windows in an array and use the E_Zone_Edge value to update just that window? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. Well I think the events are nice because they do provide a bit more information like mouse position and such which can be useful. Shelves use this if they are not spread across the entire edge. The only goal with this is to force them to use the wrapper so we can still properly show/hide the edge. This would then require that the edge have no registered event handlers and no bindings as well. At first I was a bit against the events, but I think I understand why they are useful. We just have to make using them a bit more elegant :) Although, we could do like you say and have an "Event" action with parameters. This would generate an event with the parameters specified which would be sent via the normal event mechanism to anyone listening to edge events. > > > > > 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. Yeah, was a long shot of an idea :) It would get rather complicated and you'd have modules possibly fighting over windows as you said. I think we can just keep the single edge window as it is now and the module will just have to watch the coordinates to determine if it is going to respond to the event or not. Are we in agreement on the fullscreen fix I made? If so I may redo it and do like I said above and put all the edge windows in an array based on the E_Zone_Edge values to make the code a bit cleaner. Having to put a case statement anytime I want to modify a certain edge gets very annoying :) I think above all that this fix is the most important to make right away as it's causing the most interference. > > > > > 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
