On Wed, Sep 03, 2014 at 10:42:38PM +0100, Michael Treibton wrote: > On 3 September 2014 22:27, Dominik Vogt <[email protected]> wrote: > > On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote: > >> Here's some of the things I'd like: > >> > >> - no more motif borders (horrible) > > > > With fvwm you can more or less configure every border style you > > want. Have you tried the themes package? Theming could be better > > integrated into the distribution, though. > > fvwm-themes? Seems old
So is fvwm. It hasn't changed much since fvwm-themes was written. > and didn't work well for me last time. 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. > >> - fluxbox style window borders > > > > Borders in fluxbox are also very configurable. Do you have a > > screenshot of what you mean? > > Here is one: http://files.samhart.net/img/misc/flux-tab-example.png - > look at the bottom border. I see. That is one of the things we never bothered to implement because it's eye candy, but actually unsuitable for real work. > >> - diff. border colors for each side > > > > Can already be done with pixmap borders. > > but why must i make pixmaps for each color that i want? i have > colorsets for this, don't i? 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. > > Could you please elaborate on what you think fvwm is missing in > > terms of scripting flexibility? (Other than fvwm's scripting > > language can be awkward - we're working on that.) > > That, and i don't like perl? Neither do I. But we can hardly add every odd scripting language to the window manager just because someone likes it. I can remember the fvwm-spinoff called scwm (scheme configurable window manager) which was (afaik) given up because scheme configuration turned out to be too slow. 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. > Everything is using dedicating embedded > things like lua from the outset, As much as I like lua myself, I doubt this claim very much. > > Note that mvwm is not going to be a brand new window manager that > > does everything from scratch. It will be a very much improved fvwm > > with maybe a few antique things removed. Regarding window > > handling and window decorations it won't change much for now. > > i think i understand that, yes. But i don't always see if this > approach is good or not - > why not write it from scratch? Because many parts of fvwm outperform all other window managers. No winodw manager comes even close to fvwm regarding the possibilities of scripting, configurability and getting nasty applications under control, or correct handling of requests from the applications. A window manager written from scratch could never comply with my requirements regarding usability. Fvwm also excels at flicker free animations, reducing redraws and server traffic which is still important for remote connections. Last but not least, there are *tons* of special hacks in fvwm that deal with certain broken applications that we would *never* be able to reproduce in completely new code or even just identify them. What we never tried to do was to follow every new fashion as it came up, or add pure eye candy, but rather think about usability. As Thomas wrote elsewhere, fvwm is the ancestor of many other window managers because it does many things right regarding *behaviour*. The looks of a window manager are really just the icing on top. > wasn't that the original intent? No. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
