Dominik Vogt wrote:
On Tue, Aug 08, 2006 at 04:31:00PM +0100, Thomas Adam wrote:
On Tue, 8 Aug 2006 16:18:41 +0100
"seventh guardian" <[EMAIL PROTECTED]> wrote:
On 8/8/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
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??
YES! Strangely enough, the infrastructure is there!! You can actually
send commands to specific aliased modules! Just use the module alias
instead of the name, and voila!
Except pipeAlias is never properly written. It seems that someone
started the job but didn't get to finish it.
The code is as good as it could be at the time Mikhael wrote it.
It's not much more than a hack that tries to guess whether the
first argument of a module was intended to be an alias (i.e. not an
option etc.). It fails in a number of cases, but we can not do much
better without rewriting the interface of some modules.
So what could be the solution to the initial problem without any kind
of rewrite?
There isn't, I'm afraid. I can perfectly understand and see the logic behind
why the flags should be sent in the packet information -- however in order
for there to be a solution to what you're proposing, it is going to mean a
rewrite most likely. This was discussed here on this list a few months ago.
If you like I will dig through the on-line archives for you.
But there is a soulution. Extend the config win packet with a
flag that indicated whether a window can be moved by the user,
i.e. the return code of the function that determines whether the
window can be moved or not.
As a possibility for 3.0, could the module interface be reworked perhaps
more extensively?
I had an idea for an ICE-based module interface that would, if well
done, be more flexible and extensible than the current system.
(It's biggest change would be that modules would no longer need to be
children of the fvwm process.)
It could solve this problem by defining a "query-flag" operation, with
an upward-compatible way of specifying flags.
FVWM already links libICE (session management uses it), so this wouldn't
add much to the size of the running process.
Is the time right to start discussing major changes for 3.0, or should I
hold this a while longer?
