On Tue, Sep 09, 2014 at 11:42:17PM +0100, Michael Treibton wrote: > On 3 September 2014 23:18, Dominik Vogt <[email protected]> wrote: > > Well, if you run into problems you can always ask for help un the > > users' mailing list. > > > >> is it still developed? > > > > Not by me, and I do not know if anybody maintains it. > > The last change was by thomas: > that was 4 years ago.
Oh, just four years? I thought it was more. :-D > > Granted. I don't like the pixmap implementation either; it was > > part of a compromise because many people kept nagging about rounded > > window edges and things like that. > > the TODO file in mvwm suggests this might get reworked? Yep, cleaning up fvwm would be rather pointless if we don't clean up the really dirty corners. > > The decision about the scripting implementation in the new core is > > still open, but we need facts and thinking about the correct > > choice of the language. > > i see these things in the TODO file: > > - The module interface (FVWM <-> Module) is a mess; consider DBUS? Or > imsg? > - Use libevent to replace the hand-rolled (and often broken) select/poll > mechanism. > - What about third-party scripting languages? How do we handle that > without requiring linking against the specific language in question? > > i don't know if all three are related to scripting core, The first two are really about communication between fvwm and the modules, and signal handling in fvwm and the modules. The module interface is somewhat related to scripting because it adds some limitations (maximum line length, parsing of data sent back and forth), but these limitations should be removed eventually. > but what does the last item mean? is that relating to a choice of > language? In a sense, yes. There's nothing really wrong with interfacing to Lua or other languages. At the moment, fvwm has a built in configuration language and three external interfaces for arbitrary commands: The binary module interface that can transport some information about events and fvwm's internal state. Then there's the PipeRead mechanism that can really run any command written in any language. It's severely limited in what information fvwm can pass to the command (environment variables and command line arguments with parameter expansion). And the third is the perllib. I have no clue how this is implemented and was never interested in using it. My guess is that it allows scripting and accessing the binary information of the module interface from a perl script. All these interfaces are very limited in what internal state of the windows and fvwm they can access. As a long term goal, I'd like to extend this so that all styles, window states, global states and events can be accessed from outside (and from the configuration language too, of course). The resulting scripting possibilities would be incredible, limited almost only by the speed of communication. So, I suggest there should be _one_ fast, internal language and _one_ relatively fast, flexible way without today's limitations (module input max. 255 characters, other commands max 1023 characters) to interface with any binary program or script. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
