Mikhael Goikhman <migo_at_homemail.com> writes:
> On 15 Sep 2004 11:20:10 -0400, Mark Gray wrote:
>>
>> Mikhael Goikhman <migo_at_homemail.com> writes:
>>
>>>> On 14 Sep 2004, Mark Gray wrote:
>>>>
>>>> o I am writing a fvwm perl module and anticipate wanting to parse the
>>>> o window_flags data upon receiving each M_ADD_WINDOW event.
>>> The proper solution is to serialize the flags without dumping C
>>> structures. Here is a discussion:
>>> http://www.hpc.uh.edu/fvwm/archive/0407/msg00186.html
>>> It is not very hard to implement what is suggested in the link without
>>> removing the current complier dependent flags. The hard part is to decide
>>> on the 50 most useful flags to be packed in two integers; I don't think
>>> we need to pass more flags, no modules use them. But I currently don't
>>> have a time to implement this in fvwm. Unfortunately.
>>> If someone implements this, I will try to find the time to support these
>>> packed flags in perl stuff, including FvwmDebug and WindowList tracker.
>> What are your feelings about adding a C Perl module to the FVWM perl
>> modules which would do this? My only experience with writing C/C++
>> Perl modules consists of working through the examples and exercises in
>> books on Perl, but it sounds like it might be a faster route to a
>> solution (faster than for me to learn the internal operations of the
>> fvwm code well enough to hack in another event to fvwm as
>> msg00186.html suggests.)
> The suggestion was not to add a new event, but new M_ADD_WINDOW fields,
> as said in the reply to that message.
Ah -- I misunderstood: I saw the reference to the M_OLD_ADD_WINDOW and
thought you wanted to revive it, and did not think to read the
followups to that post.
>> The biggest problem I can see with adding a C Perl module to fvwm's
>> perllib, is in the build process on unknown platforms -- not
>> everyone is going to even have their systems in a state that is
>> capable of compiling a C Perl module (old Redhat Linux systems come
>> to mind).
> There are multiple reasons why I don't like to compile anything Perl
> specific, but if you want to go this path, you may try. The "make" step
> may compile and run some C program that generates Perl class
> FVWM::WindowFlags. There is a problem then of maintaining this program,
> it would be a lot of annoying code that duplicates the huge non-flat
> window_flags structure in C. I prefer the solution with 50 most useful
> flags to be packed and sent to modules, so that it would not be perl
> specific, this does not really require maintainance, since the most
> useful flags are not likely to be removed. But I don't care to support
> all 300 flags if someone wants to maintain this generating program.
> Just please keep in mind that currently the Perl stuff is fully
> transparent, it is not even required that Perl is installed before
> installing fvwm. I want to continue with this.
I agree with everything you say. Arranging for the building of perl
c-modules on unknown and unseen systems is a daunting task -- I have
often had to modify modules I have downloaded from CPAN in order to
get them to build, even on the most up to date and correctly
configured systems.
But I really like your suggestion about a C program which will
generate a perl only FVWM::WindowFlags, and I will look into doing so.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Sep 16 2004 - 09:39:07 BST