I have a question about these: 18) Split style lists into 5 (resource, class, icon, name, id). 19) Styles get applied in the above order. 20) Split each style list into two (one with wildcards, one without).
The current way style commands work is that the last one given takes precedence. Won't 20 and possibly 18 and 19 break that? Won't that be too hard for a user to understand? On another subject, I'm pretty sure I heard (read|saw) Dominik make some comment about modules using stdin/stdout instead of the FDs that they use now. I guess that would kill off that array of longs being passed, instead plain text commands could be passed to the module. Possibly modules could be tested outside Fvwm. It sounds like a great idea to me, but it didn't make the todo list. Maybe it doesn't belong on the todo list, Dominik has said that the pipes are too slow. I haven't seen that myself, FvwmAnimate seems to be very responsive. On a similar note, theres this: 6) Change FvwmCommand to use the socket and readline, remove FvwmCommandS. This is sockets instead of X properties. Doesn't X use pipes when $DISPLAY is not a host name (:0.0), for performance reasons? I think the other 2 choices are shared memory semaphores and dlopen. Shared memory can be fast (I don't have numbers), but when I configured XSun to use it, it didn't make any noticeable difference. I have run into applications that can't get enough shared memory and I've needed root access to get past that problem. I think the dlopen APIs would be as fast as we could get, but I'd guess they would cause portability problems. -- Dan Espen E-mail: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
