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.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
