> > >-------- Original Message -------- >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. FVWM is not more extensible than it would be if it was OO. FVWM does not integrate as easily with third party code, as it would if it was OO. Regarding database integration, pretty much every *nix programming environment has existing libs for integrating with sqlite, no pipelining required. 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. 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. Or in other words: FVWM is not more hackable, than it would be if it used SQL as configuration repository. FVWM is not more syntactically stable, than it would be if it used SQL... FVWM is not more supportable, than it would be if it used SQL. 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. 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. 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. Perhaps I'm making a bad assumption. Is increased usership a goal of the FVWM development team? Thanks!
