<msib...@crosswire.com> writes: >>Subject: Re: FVWM: GSoC 2012: Project ideas >>From: Jaimos Skriletz <jai...@diamond.boisestate.edu> >>Date: Thu, February 23, 2012 4:32 pm >>To: fvwm@fvwm.org >> >> >>On Thu, Feb 23, 2012 at 01:34:38PM -0700, msib...@crosswire.com wrote: >>> >>> Not trying to piss anyone off. IMHO, I'm just stating the obvious. There >>> is more holding FVWM back than what can be fixed with debugging. >>> >> >>Holding FVWM back from what? >> > > <SNIP> > > FVWM is not more portable than it would be if it was Object Oriented.
I'm at 100% loss to understand what you are talking about. Are you claiming C++ is more portable than C? I don't think the facts bear that out. They days of Sun workstations, AIX desktops, etc. are fading, but in the past Fvwm served all those users and more. > FVWM is not more extensible than it would be if it was OO. Really? The most extensible WM of all would be more extensible if it relied on name mangling and all the other kludges present in OO languages? > FVWM does not integrate as easily with third party code, as it would if > it was OO. Bull. Fvwm provides all kinds of interfaces, including our much used module interface. I'd need to see some concrete examples to be convinced. > Regarding database integration, pretty much every *nix programming > environment has existing libs for integrating with sqlite, no pipelining > required. Yes, fvwm could drag every open source package in the world into it's core. > My interest is not so much in the database, but in the fact that it > improves syntactical constraint, extensibility, and supportability in > one include statement. Mystified. Fvwm relies on procedural commands. Not just from it's configuration files but from modules and other interfaces. There is nothing more flexible, or extensible. > The same motives are behind using WxWidgets. Wx, > and Sqlite integration would reduce the rewrite time to version 1.0 by a > significant amount, and with decent design practices, if you still want > Xlib, go ahead. Just write an Xlib based widget object and include it as > a plugin or a module. Nothing prevents that. Fvwm is version 2.6, not 1.0. We have no interest in obsoleting our users configuration files. Every time we make an incompatible change, we supply a conversion script. > Or in other words: > FVWM is not more hackable, than it would be if it used SQL as > configuration repository. Right, if fvwm procedural commands were stored in SQL they'd work just the same. Except a special editor would be required to make changes. > I really don't know why ya'll look at this box of bones and think it is > as sexy as steak. the world has progressed. I use FVWM because I do a > lot of my own automation with it. FVWM is uniquely kludgable. But the > juice/squeeze ratio when working with FVWM is terrible. Don't know what a juice/squeeze ratio is. If you have a point, please speak in plain terms. > I have seen many times on this list, a prevelance of a bizarre attitude > that any programatic logic a third party should wish to integrate with > FVWM, should be done within the configuration of FVWM itself, and that > any other solution is bad. BS. Is this you Harry? Haven't you wasted enough of our time? > Yet FVWM's configuration syntax is incredibly intolerant of anyone who > isn't an old-school C programmer. It certainly isn't in the interest of > expanding usership to continue down that path. Fvwm commands don't use C syntax. > Perhaps I'm making a bad > assumption. Is increased usership a goal of the FVWM development team? Fvwm is for users that want complete control of their desktop with minimal resource use and ultimate flexibility. Since no one else has EVER called for the kinds of changes you've proposed I don't think you are in a position to decide what our users want. -- Dan Espen
