On Tue, 8 Aug 2006, seventh guardian wrote:
On 8/8/06, Viktor Griph <[EMAIL PROTECTED]> wrote:
On Tue, 8 Aug 2006, seventh guardian wrote:
> On 8/7/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
>> > Is there any way that the module interface allows keeping track of
>> changes
>> > to the window flags of a window? Currently FvwmPager allows moving of
>> > FixedPosition mini-windows, but the main window does not move. Just
>> > checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition
>> flag
>> > was set after the window was added to the pager (i.e with 'WindowStyle
>> > FixedPosition') since the flags get outdated.
>> >
>> > I've been looking some at the module interface, but I think that no
>> > message exist to indicate change in window flags. Is this correct?
>>
>> Actually, the window flags are part of some message, but they should
>> not be used. Looking at a flag does not solve the problem anyway
>> because the decision whether a window can be moved or not is much
>> more complex (affected by a number of styles).
>>
>
> What about providing modules a way to ask fvwm to move the windows
> instead of the module moving them through X calls? This way the
> "sanity checks" would be done in fvwm, leaving all these problems to
> the window manager. It would work the same as moving the viewport. The
> pager asks fvwm to move the viewport, it doesn't directly move all the
> windows.
>
> But it would require a rewrite of the pager, and some major changes to
> the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be
> a >2.6 feature?
>
The mechanism for asking fvwm to move a window is already there. It's just
to send the Move command. However, this does not fix the problem, since
there is no way for the pager to know if the move was successful or not.
It could move the mini window back to te original position on button
release and then send the move command and wait for a corresponding
configure-package to know the new position if the window was moved. This
however would cause windows jumping back and forth in the pager.
Some sort of meanpath would be to add a message for ignored requests and
have it have the same info as the configure window package, but that's
definately a hack. Both these 'solutions' would allow the miniature window
to move, but have them jump back on non-moveable windows. The best thing
would be to not allow movement on non-moveable windows to start in the
pager view.
Well, it could work properly. Just ask for a null move (move the
window to its current position) as soon as the user tries to move the
miniwindow. If the command was rejected fvwm issues a simple error
packet. The Pager now knows it can't move the window. If the command
wasn't rejected then the pager can send the real Move command, to move
the window to its new position.
While this could work, it probably requires a largeer rewrite of the
pager code to allow it to wait for a response from fvwm before starting
the move. This resoponse can come mixed with several other messages that
has to be taken care of in the normal way.
What about adding a command to check for movement ability (CanMove or
something like this)? This way fvwm would tackle the multiple style
conflicts, and the pager needed to know nothing about the actual flags
and stuff. Also, no new packet would be required. It would work the
same way as the above solution, so the above could be simpler.
A CanMove command is not needed, and not desireable. Instead it should be
a 'Movable' conditional, which probably is quite easy to add. There is
still one problem, that already affects the code somewhat: The
SendToModule command can be used to send instructions back to the module
on a successful test. However, it can only direct the messages by name,
which mean that they might get to multiple instances of a module. Properly
designed messages, in combination with the module knowing which messages
it's waiting for can solve this, but it would be nice for a way for a
module to uniqely define itself to fvwm as a recipent in a SendToModule
command.
/Viktor
