subject:"\[E\-devel\] Fix issues with edge bindings"

Re: [E-devel] Fix issues with edge bindings

2009-09-05 Thread Vincent Torri

On Sat, 5 Sep 2009, Carsten Haitzler (The Rasterman) wrote:

On Fri, 4 Sep 2009 16:13:10 -0500 Nick Hughart mek...@mekius.net said:

On Thu, 3 Sep 2009 10:57:35 +1000
Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:

On Sat, 29 Aug 2009 18:56:22 -0500 Nick Hughart mek...@mekius.net
said:

edge bindings have fundamental design flaws - as you picked up. 1.
original invisible input-only windows were fine as they were only
ever thereon a border you can flip over. on the ones you can't - they
never were there. as a flip timeout is short (like 0.5 sec
normally) that is the period of time u might want to use that edge
(click a window title to move it, press a button in an apps window),
before it will flip. this makes it practically never that this is
the case.

as of edge bindings this window is ALWAS there stealing input. i have
noticed this already - trying to hit a window titlebar to drag it
when my mouse is at the top of the screen. the edge binding traps it.
this in general is bad.

imho edge bindings - while cool, suffer from an x limitiation. we
cannot just snoop all events without interfering with them in some
way (ie trapping them and not passing them on etc.). the only way
this is possible is xevie at the moment. imho - until xevie is being
used, i dont think having bindings for regions of the screen is a
good idea. we need to handle these on a special case basis - as the
old edge flip code did for edge flipping. the problem is the shelf
autohide. to be honest - i don't think it's possible to do. you will
ALAYS steal the whole bottom edge of the screen for it (or whatever
edge the shelf is along). lets say its the top edge. this means if i
have a titlebar there, i can't just woosh my mouse to the top of the
sceen, click and drag as the edge binding steals it (for shwoing the
shelf). my opinion is this.

1. remove edge event and bindings. wait for xevie to be used - then
we see ALL mouse events and can make any region of the screen
passively listen to events and do anything we like.
2. bring back the old edge flip code
3. disable shelf autoshow/hide (sorry just not going to work given
current infrastructure).

to do this right we need to

1. use xevie and become an event translator and manager (xevie is
for events what window management is for window positions/sizes etc,
or a composite manager is for pixels. it gets every vent and you have
a chance to modify it or just pass it back as-is, but a bi-product is
actually seeing all thew mouse events no matter where).
2. move from edge bindings to screen region bindings (not just
edges just any area).

Well this would be great if Xevie had a future. From the FDO page:

It has been suggested that this extension should not be used because
it is broken and maintainerless.

and

XEvIE has been removed from HEAD on Wed Oct 22:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a;

oh crap. i know there was talk of it being unloved but its the ONLY way to do
this. i did't know it was removed.there's no other event monitor (and intercept)
mechanism in x.

Using Xinput2, maybe ?

Vincent

So unless we actually pick it up it would seem like noone is interested
in doing it. I agree it's the best way to go about it, but doesn't
seem like it's going to happen anytime soon heh. Do you know if there
were any technical reasons for it's departure?

no - just rumblings of unhappiness. but it stayed. this creates a chunk of
problems. now it seems it's gone. bugger. crap. what to do...

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.

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.

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.

Re: [E-devel] Fix issues with edge bindings

2009-09-04 Thread The Rasterman

On Fri, 4 Sep 2009 16:13:10 -0500 Nick Hughart mek...@mekius.net said:

On Thu, 3 Sep 2009 10:57:35 +1000
Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:

On Sat, 29 Aug 2009 18:56:22 -0500 Nick Hughart mek...@mekius.net
said:

to do this right we need to

Well this would be great if Xevie had a future. From the FDO page:

It has been suggested that this extension should not be used because
it is broken and maintainerless.

and

XEvIE has been removed from HEAD on Wed Oct 22:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a;

oh crap. i know there was talk of it being unloved but its the ONLY way to do
this. i did't know it was removed.there's no other event monitor (and intercept)
mechanism in x.

no - just rumblings of unhappiness. but it stayed. this creates a chunk of
problems. now it seems it's gone. bugger. crap. what to do...

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.

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.

Re: [E-devel] Fix issues with edge bindings

2009-09-04 Thread Nick Hughart

On Thu, 3 Sep 2009 10:57:35 +1000
Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:

On Sat, 29 Aug 2009 18:56:22 -0500 Nick Hughart mek...@mekius.net
said:

to do this right we need to

Well this would be great if Xevie had a future. From the FDO page:

It has been suggested that this extension should not be used because
it is broken and maintainerless.

and

XEvIE has been removed from HEAD on Wed Oct 22:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a;

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.

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

Re: [E-devel] Fix issues with edge bindings

2009-09-03 Thread The Rasterman

On Sat, 29 Aug 2009 18:56:22 -0500 Nick Hughart mek...@mekius.net said:

edge bindings have fundamental design flaws - as you picked up. 1. original
invisible input-only windows were fine as they were only ever thereon a border
you can flip over. on the ones you can't - they never were there. as a flip
timeout is short (like  0.5 sec normally) that is the period of time u might
want to use that edge (click a window title to move it, press a button in an
apps window), before it will flip. this makes it practically never that this
is the case.

as of edge bindings this window is ALWAS there stealing input. i have noticed
this already - trying to hit a window titlebar to drag it when my mouse is at
the top of the screen. the edge binding traps it. this in general is bad.

imho edge bindings - while cool, suffer from an x limitiation. we cannot just
snoop all events without interfering with them in some way (ie trapping them
and not passing them on etc.). the only way this is possible is xevie at the
moment. imho - until xevie is being used, i dont think having bindings for
regions of the screen is a good idea. we need to handle these on a special case
basis - as the old edge flip code did for edge flipping. the problem is the
shelf autohide. to be honest - i don't think it's possible to do. you will
ALAYS steal the whole bottom edge of the screen for it (or whatever edge the
shelf is along). lets say its the top edge. this means if i have a titlebar
there, i can't just woosh my mouse to the top of the sceen, click and drag as
the edge binding steals it (for shwoing the shelf). my opinion is this.

1. remove edge  event and bindings. wait for xevie to be used - then we see ALL
mouse events and can make any region of the screen passively listen to events
and do anything we like.
2. bring back the old edge flip code
3. disable shelf autoshow/hide (sorry just not going to work given current
infrastructure).

to do this right we need to

1. use xevie and become an event translator and manager (xevie is for events
what window management is for window positions/sizes etc, or a composite manager
is for pixels. it gets every vent and you have a chance to modify it or just
pass it back as-is, but a bi-product is actually seeing all thew mouse events
no matter where).
2. move from edge bindings to screen region bindings (not just edges just any
area).

 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.
 
 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.
 
 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.
 


-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
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

Re: [E-devel] Fix issues with edge bindings

2009-09-01 Thread Viktor Kojouharov

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

Re: [E-devel] Fix issues with edge bindings

2009-09-01 Thread Nick Hughart

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

Re: [E-devel] Fix issues with edge bindings

2009-08-30 Thread Viktor Kojouharov

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).

 
 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.

 
 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

Re: [E-devel] Fix issues with edge bindings

2009-08-30 Thread Viktor Kojouharov

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

[E-devel] Fix issues with edge bindings

2009-08-29 Thread Nick Hughart

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.

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.

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.
Index: src/bin/e_bindings.c
===
--- src/bin/e_bindings.c	(revision 42093)
+++ src/bin/e_bindings.c	(working copy)
@@ -414,7 +414,12 @@
 e_bindings_edge_add(E_Binding_Context ctxt, E_Zone_Edge edge, E_Binding_Modifier mod, int any_mod, const char *action, const char *params, float delay)
 {
E_Binding_Edge *bind;
-   
+   Eina_List *l, *ll, *lll;
+   Eina_List *mans, *cons;
+   E_Manager *man;
+   E_Container *con;
+   E_Zone *zone;
+
bind = calloc(1, sizeof(E_Binding_Edge));
bind-ctxt = ctxt;
bind-edge = edge;
@@ -424,6 +429,44 @@
if (action) bind-action = eina_stringshare_add(action);
if (params) bind-params = eina_stringshare_add(params);
edge_bindings = eina_list_append(edge_bindings, bind);
+
+   /* Update all zones to show the edge */
+   EINA_LIST_FOREACH(e_manager_list(), l, man)
+ {
+	EINA_LIST_FOREACH(man-containers, ll, con)
+	  {
+	 EINA_LIST_FOREACH(con-zones, lll, zone)
+	   {
+		  switch(edge)
+		{
+		 case E_ZONE_EDGE_LEFT:
+		   ecore_x_window_show(zone-edge.left);
+		   break;
+		 case E_ZONE_EDGE_TOP:
+		   ecore_x_window_show(zone-edge.top);
+		   break;
+		 case E_ZONE_EDGE_RIGHT:
+		   ecore_x_window_show(zone-edge.right);
+		   break;
+		 case E_ZONE_EDGE_BOTTOM:
+		   ecore_x_window_show(zone-edge.bottom);
+		   break;
+		 case E_ZONE_EDGE_TOP_LEFT:
+		   ecore_x_window_show(zone-corner.top_left);
+		   break;
+		 case E_ZONE_EDGE_TOP_RIGHT:
+		   ecore_x_window_show(zone-corner.top_right);
+		   break;
+		 case E_ZONE_EDGE_BOTTOM_RIGHT:
+		   ecore_x_window_show(zone-corner.bottom_right);
+		   break;
+		 case E_ZONE_EDGE_BOTTOM_LEFT:
+		   ecore_x_window_show(zone-corner.bottom_left);
+		   break;
+		}
+	   }
+	  }
+ }
 }
 
 EAPI E_Binding_Edge *
@@ -445,25 +488,74 @@
 e_bindings_edge_del(E_Binding_Context ctxt, E_Zone_Edge edge, E_Binding_Modifier mod, int any_mod, const char *action, const char *params, float delay)
 {
E_Binding_Edge *bind;
-   Eina_List *l;
+   Eina_List *l, *ll, *lll;
+   Eina_List *mans, *cons;
+   E_Manager *man;
+   E_Container *con;
+   E_Zone *zone;
+   int ref_count = 0;
 
EINA_LIST_FOREACH(edge_bindings, l, bind)
  {
-	if ((bind-ctxt == ctxt) 
-	(bind-edge == edge) 
-	(bind-mod == mod) 
-	((bind-delay * 1000) == (delay * 1000)) 
-	(bind-any_mod == any_mod) 
-	(((bind-action)  (action)  (!strcmp(bind-action, action))) ||
-	 ((!bind-action)  (!action))) 
-	(((bind-params)  (params)  (!strcmp(bind-params, params))) ||
-	 ((!bind-params)  (!params
+	if ((bind-edge == edge))
 	  {
-	 _e_bindings_edge_free(bind);
-	 edge_bindings = eina_list_remove_list(edge_bindings, l);
-	 break;
+	 if ((bind-ctxt == ctxt) 
+		 (bind-mod == mod) 
+		 ((bind-delay * 1000) == (delay * 1000)) 
+		 (bind-any_mod == any_mod) 
+		 (((bind-action)  (action)  (!strcmp(bind-action, action))) ||
+		   ((!bind-action)  (!action))) 
+		 (((bind-params)  (params)  (!strcmp(bind-params, params))) ||
+		   ((!bind-params)  (!params
+	   {
+		  _e_bindings_edge_free(bind);
+		  edge_bindings = eina_list_remove_list(edge_bindings, l);
+	   }
+	 else
+	   ref_count++;
 	  }
  }
+
+   /* Hide edge/corner in all zones if no more bindings exist */
+   if(!ref_count)
+ {
+EINA_LIST_FOREACH(e_manager_list(), l, man)
+	  {
+	 EINA_LIST_FOREACH(man-containers, ll, con)
+	   {
+		  EINA_LIST_FOREACH(con-zones, lll, zone)
+		{
+		   switch(edge)
+			 {
+			  case E_ZONE_EDGE_LEFT:
+			ecore_x_window_hide(zone-edge.left);
+			break;
+			  case E_ZONE_EDGE_TOP:
+			ecore_x_window_hide(zone-edge.top);
+			break;
+			  case E_ZONE_EDGE_RIGHT:
+			ecore_x_window_hide(zone-edge.right);
+			break;

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

Re: [E-devel] Fix issues with edge bindings

[E-devel] Fix issues with edge bindings

9 matches

Site Navigation

Mail list logo

Footer information