Okay I got it I think. The problem is if a window does a pointer grab it should get the grabbed dropped if another window goes on top. Now I need to see if its a window manager bug or a gdk bug prob a gdk it looks like I'm not dropping the grab window when the stacking order changes buuuut I need to know if its now below a window that takes focus. Also I don't like the grab code being up in gdk it should be down in the wm. No time to look right now gotta head west :(
Mike On 1/29/06, Mike Emmel <[EMAIL PROTECTED]> wrote: > On 1/29/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > Mike Emmel wrote: > > > On 1/27/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > > > > >>Mike Emmel wrote: > > >> > > >>>On 1/27/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > >>> > > >>> > > >>>>Mike Emmel wrote: > > >>>> > > >>>> > > >>>>>Hi Denis it was my understanding they by default if a window is 100% > > >>>>>clear i.e alpha=0 that it will not receive events by default is this > > >>>>>true or false ? > > >>>>>Note this is different from being shaped. > > >>>> > > >>>>The alpha channel only matters if DWOP_SHAPED is used. > > >>>> > > >>> > > >>>So hidden windows with alpha 0 still get events ? > > >>>It would be nice to distinguish a totally clear window an not receive > > >>>events. > > >>>This is different from being shaped I think. > > >>>The problem is we are using alpha to mean shown or hidden. > > >> > > >>1. Why should one create a completely transparent window? > > >>2. It would be too expensive to check for it :) > > >> > > > > > > Thats how we attache the windows in directfb before there shown. > > > > Before windows are shown they should be filled with the content > > that is about to be shown :) > > > That I have little control over bummer :( > > > > There is no concept of a hide and show in directfb so we use the clear > > > window > > > to represent a hidden window. The problem is unless the shaped bit is > > > set they > > > get events. When there shown then the opacity is set to 0xFF ( should > > > be the default value but that can be fixed easily ). > > > > > > Since its the global opacity I don't think its expensive to check for > > > I like the idea of just using global opacity and not having hidden > > > windows but we do need a way to turn of events when the windows are > > > "hidden". > > > > SetOpacity(0) hides the window and prevents events being sent to it nd > > > Okay thats what I thought and that is what seems to be happening in > window_at_pointer in default.c > > In any case it seems to be pretty much right and behaves as I understand it. > I think there is a window ordering bug somewhere thats showing up in > gtk so I need to chase it down events are going to the wrong windows. > > > > > My view with shaped windows is that there expensive for mouse event > > > handling is this not true ? > > > > Doesn't seem so on system that make use of this feature. > > > I meant when its set then you have to fallback to a pixel hit test for > pointer in window > instead of using the bounds. I think that can be and expensive call. > Okay wrong again your just checking alpha at the pixel under x,y... I > was thinking of the wrong test xy in region. > > Okay sorry for the fuss everything looks right I just wanted to make > sure I did not make a mistake in my assumptions as I chase some of > the wierd focus bugs were having. > I think I can also play with the GHOST option it will help me debug. > > Sorry to waste your time great Directfb jedi master :) > > Mike > > > -- > > Best regards, > > Denis Oliver Kropp > > > > .------------------------------------------. > > | DirectFB - Hardware accelerated graphics | > > | http://www.directfb.org/ | > > "------------------------------------------" > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
