On 8/23/06, Jacob Bachmeyer <[EMAIL PROTECTED]> wrote:
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?
This may not be the right time to start the "final" discussion, but I
guess no one will complain about us "spaming" the fvwm mailing list :P
As for this discussion, IMHO the best thing to do first is to abstract
ourselves from the actual communication method. We first define an
interface over a generic bidirectional stream, then we can implement
it over any kind of mechanisms. Being it pipes, ICE, DBUS, dynamic
loaded libraries, TCP/IP.
If we manage to work out a good abstract interface, it wouldn't be
hard to implement it using ICE..
Cheers
Renato
