Mikhael Goikhman <[EMAIL PROTECTED]> writes: > On 15 Sep 2004 11:20:10 -0400, Mark Gray wrote: >> >> Mikhael Goikhman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
