Right ... that is what I think also .. in a sense

Denis
So if I'm going to implement dfb_window_move in unique,
should I add it in context? or windows?
This is something I'm not very sure ...I put
move_window( ctx , event->pointer.x , event->pointer.x );
in the _unique_window_input_channel_listener ... and now
I can move the gtk windows in unique

however I find another funny thing also is when I click on
the frame( decorator ) my windows seem to lot contact... I'm
not sure ... my mouse no longer get any effect to any window
at all.


Kent Sandvik wrote:
> On 1/4/06, Mike Emmel <[EMAIL PROTECTED]> wrote:
>>> I think unique still uses the primitive key based movments.
>> But I really don't use either unique or LiTE much so your getting
>> outside the areas I know.
> 
> I'm not sure about the question. In general LiTE should be agnostic
> about any window manager used as it just creates the basic window and
> surface structures, and gets event input from whatever the window
> manager provides.
> 
> There's the special issue of minimizing/maximizin windows that's
> inside LiTE and depending on the behavior in the window manager this
> might cause problems, i.e. two ideas how that's done. It might be that
> we should refactor this and make it an option inside LiTE (will add
> that to the todo list).
> 
> The other issue is window decoration, I think that's also where the
> LiTE system and any window manager could also clash -- we need to
> think more about that, as well.
> 
> Otherwise, plain window movement with the mouse should be OK, and the
> window stacking is done by any specific window manager.
> 
> --Kent
> 
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
> 


_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to