Re: FVWM: GSoC 2012: Project ideas
A scratch rewrite in C++, using WxWidgets and embedding the configuration elements in sqlite, killing configuration files for good and ever. There is a point at which you are doing yourself a favor by shooting the horse instead of feeding it. 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. Matt Original Message Subject: FVWM: GSoC 2012: Project ideas From: Thomas Adam Date: Thu, February 16, 2012 6:06 am To: fvwm@fvwm.org All, Whilst I appreciate that organisations need not worry about this until the end of February, I'll be moving house then so I need to start thinking about this now, rather than later. Now that 2.6.0 is out, I'm proposing the following project (some of which are a continuation from previous GSoC proposals) -- none of which are listed in any order. * Style clean-up (Difficulty: Easy): This would involve thinking about the internal state of styles. At the moment, we've a complete bomb-site in fvwm/styles.c in the form of a huge case statement which is responsible for dishing out random code to act on windows. I'd like to see this mechanism replaced with something more like a dispatch-state, involving stucts and callbacks. I've very tentatively started this here: https://github.com/ThomasAdam/fvwm/commits/ta/style-cmd-tweaks This is a pre-requisite step for many other style-related project proposals though -- but still something which is a good enough project in its own right. * Finer-grained style matching (Difficulty: Medium): Currently there is no direct way to match specific components of windows when putting styles to them -- the only way you can do this at the moment is through clever ordering of style lines. This project would therefore flesh out ideas to allow for specifiers for which window to match based on a windows's name, class, resource, or icon name. Perhaps in the form: Style (Name=xteddy,Class=XTeddy) Sticky ... where these styles are logically ANDed together, rather than ORed, to avoid the need for specific style-line ordering. * Unification of window commands/states to provide a consistent interface (Difficulty: Hard) Style (and WindowStyle) affect the state of windows, as well as specific commands which are not style-options but still affect the state of windows. There has long-since been an idea to unify this, and to split the entire concept into two states: - The initial state of windows (perhaps with an InitialState command) - Subsequent window operations happen with a WindowState command So you could think of this as FVWM commands at present which aren't style-related (but which operate on windows anyway) deprecated in that you have to set states of windows to have them work. Here's an example: # All windows' initial state are set like this. InitialWindowState * SetWindowState WindowShade E, Maximize 100 100 # I want to control "XTermA" to never windowshade. In setting this, as it's # already a running program, that specific window's state has changed, and # only that window. Next (XTermA) SetWindowState WindowShade Off # I want all XTerm windows to have a specific window state of iconified. InitialWindowState (Name=xterm,Class=XTerm) Iconify On Thus, all that happens in unifying the commands to properties on windows is a stack of things which are applied/unapplied as appropriate. This change is huge though, and would need more discussion. * Decor code to be modularised (Difficulty: Medium): Finally deprecated the decoration code as being in the core, and instead allow for this to be handled with a FvwmDecor module (or some such name). Some thought would need to be put in to how this is handled by modules, as there should be some means to allow more than one module to decorate a given window. This will require a change in libs/vpacket.h as well as the module information. * Allow fine-grained control of window decors (Difficulty: Hard): If we ever want to allow users to customise the colour and/or which parts of a decor is rendered, we need to rethink the FW_FRAME construct, and how that's rendered in terms of its current GC implementation. A module would need to do this -- as well as defaulting to a base decor (such as a MWM look?) Shape-masking might be a possible to do this. This would also allow for bling features like rounded-corners. This is obviously the future now, where bling is more important than functionality. Comments welcome, or even ideas. -- Thomas Adam
Re: FVWM: GSoC 2012: Project ideas
On Thu, Feb 23, 2012 at 01:34:38PM -0700, msib...@crosswire.com wrote:
>
> A scratch rewrite in C++, using WxWidgets and embedding the
Rewrites do not work. They really don't. IBM can tell you that from
experience.
As for basing a window manager off a widget library, I will point you
towards the likes of GNOME, where applications linking to things like GTK
are trampled all over when the assumptions about the window management leak
out entirely to the widget library.
The point of FVWM written in Xlib is that it's the correct and lowest common
denominator for being able to do anything portable. That was true in 1993
and it's still true now. You do not need a widget library to implement
things like window borders, and even if you did, that would still not imply
some free or extra functionality we wouldn't need to write.
> configuration elements in sqlite, killing configuration files for good
> and ever. There is a point at which you are doing yourself a favor by
> shooting the horse instead of feeding it.
We do this because we _like_ doing it, not because we cling to the last
vestiges of some bygone era. FVWM is what it is, *because* that's what it
is. There is nothing in FVWM which needs or facilities a rewrite, and
improving on features I've mentioned either in this thread or elsewhere is
perfectly feasible in smaller chunks.
That's called programming. And that's why it's fun.
-- Thomas Adam
P.S. Don't top-post on this list again.
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: FVWM: GSoC 2012: Project ideas
Am Donnerstag, 23. Februar 2012 schrieb msib...@crosswire.com: > A scratch rewrite in C++, using WxWidgets and embedding the > configuration elements in sqlite, killing configuration files for good > and ever. There is a point at which you are doing yourself a favor by > shooting the horse instead of feeding it. > > 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. There are very good reasons for using plain text files. These reasons are so good, that every programmer uses plain textfiles for his sourcecode (ok, there was once an IDE from a big big vendor ... but that thing died) Despite, I cannot remember that the windows registry database was a very clever design decision. Nik
Re: FVWM: GSoC 2012: Project ideas
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? FVWM does its function really well. It is a configurable and stable wm that works on most systems. Sure there are a few things here and there that could be added or improved in fvwm and some bigger projects that would be nice, yet over all FVWM preforms its task well. I don't see FVWM being held back from anything. People use it for different reasons. I myself use FVWM because it is fun, light weight, and requires few dependencies. I have the ability to do most of what I want out of a WM (sure some things are lacking but they aren't a game breaker). If I didn't want to use a text based config file, or really wanted a different widget set there are plenty of other choices of WMs or even DEs to choose from. I don't think it was ever in FVWMs goals to be the all-in-one window manager. Over the 20 years of fvwm's existance there have been forks, derivatives, and even complete rewrites of these forks (spawning a new window manager) that take some ideas from FVWM, but these are no longer FVWM. It seems xfce even had its origins from FVWM but after a few complete rewrites is now a full desktop envorment. So this idea is not new, and many people really enjoy some of the rewrites of the derivatives, but FVWM is still around. jaimos
Re: FVWM: GSoC 2012: Project ideas
> > > Original Message >Subject: Re: FVWM: GSoC 2012: Project ideas >From: Jaimos Skriletz >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? > 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!
Re: FVWM: GSoC 2012: Project ideas
writes: >>Subject: Re: FVWM: GSoC 2012: Project ideas >>From: Jaimos Skriletz >>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? >> > > > > 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
