Thanks for the reply,
I guess the real fix should be within gdkdfb and I will take a
look at it.
Then next question come to the handling the window moving,
should I handle the foo input inside the class/foo.c
and then dispatch the input as normal ( right now I handle
all the widget moving and resizing in the window.c
And when you saying send the resizing to the slave window
does it mean e.g. send resize window to the gdk? (in my case )
I see the foo get input channel also, and when you say decoration
input channel.. are they the same thing you are talking about?
Final question what is the use of the unique_window_notify?
Also the unique_window_dispatch function seem to be empty! :)
and it case seg fault and not exit normally with unique enable.
Denis Oliver Kropp wrote:
> Alex Lau wrote:
>> Dear all
>>
>> I'm not sure this is a right fix but some how in the gtkfb
>> the unique will create a decorate window as big as screen
>> and not visible, so when you click on the foo it will call
>> the grab window and the pointer input channel will be switch
>> to a invisible layer, so I put a test of the window->opacity
>> before the switch
>>
>> --- window.orig 2006-01-06 00:39:21.000000000 +0800
>> +++ window.c 2006-01-06 00:38:41.000000000 +0800
>> @@ -492,8 +492,13 @@
>> UDCI_KEYBOARD,
>> window->channel );
>>
>> case CWMGT_POINTER:
>> + if( window->opacity )
>> return unique_input_switch_set( context->input_switch,
>> UDCI_POINTER,
>> window->channel );
>> + else {
>> + //printf("Alex say this is not good so don't set!\n");
>> + return DFB_OK;
>> + }
>>
>> case CWMGT_KEY: {
>> DFBResult ret;
>>
>>
>
> Well, the default WM also allows pointer grabbing by invisible windows...
>
> The real problem seems to be that gtk doesn't cope with the event
> outside of its window and redirects it to the root window :-(
>
> But the foo stuff in Unique is not finished, it's a placeholder
> or at least experimental. It's too concrete as Unique should be
> the framework for all different kinds of decorations, implemented
> outside of or at least as a plugin for Unique.
>
> In the end, the events of the decorations shouldn't go to the
> window's input channel, but to a dedicated input channel for
> the decoration implementation.
>
> Parts of the decoration code will be run in the master, other
> parts in the slave (owner of the window). For example, moving
> should be done in the master, while resizing should be done by
> each slave itself, to preserve the nice synchronous resize/repaint
> that you have e.g. with LiTE today.
>
> If the master resizes the window and the slave receives the event
> and repaints the window, you will see a lot of flashing and other
> artifacts when there is a new resize before the old one got handled.
> Synchronization would be very complicated and drag the performance
> down. It's better to send only resize requests to the slave and have
> it resize/repaint itself.
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
