On 8/8/06, seventh guardian <[EMAIL PROTECTED]> wrote:
On 8/8/06, Viktor Griph <[EMAIL PROTECTED]> wrote:
> 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.
It would be easy to uniquely identify the modules if the alias' were
managed by fvwm instead of the modules. This way fvwm would know which
specific module was listening on which pipe. As a (positive) side
effect, modules wouldn't need to know their alias, which in turn would
make the message requesting/parsing easyer.
I've already suggested this, but it was said to be too complicated to
be worth implementing before 2.6.. Things that needed to change:
-Change of the module interface code in fvwm.
-Add a command/style to specify the module alias in the config file. -
VISIBLE (new feature)
-Minor changes to the module's config parsing code.
-The module's parsing cmd line options (now reject the alias options). - VISIBLE
(could break backward-compatibility)
As a way to provide backward compatibility and minimizing the effects
of the above VISIBLE changes there could be provided a command that
the modules could use to request an alias. This way the module would
parse the command line alias options and request the attribution of an
alias. So old configs would still work properly!! :)
Strange thing now looking through module_interface.c: there is already
a string array called pipeAlias!! Is it possible that the
infrastructure is already there??
Renato
Cheers
Renato
> /Viktor
>
>
