Fvwm... but not fvwm...

I’ll try to make this short and simple:

These are the two main FVWM features that I am referring to in this post:
– mouse and key bindings
– control over windows (EWMH)

No other window manager or application comes close to providing users with control over the above features like FVWM does. However, I want to use the above features in a DIFFERENT window manager. Basically, I’d like to see the above features in a standalone application, one that can interface with any EWMH compliant window manager. Essentially, this would be a combination of wmctrl and xbindkeys (only a lot more powerful).

Almost all of the code to accomplish this is already inside FVWM. Would it be that hard to just strip it out and write a standalone application, one that works with any EWMH window manager?

Is anyone interested in pursuing this? Or is this just a stupid idea?

  • Phil

In order for that to happen, the WM in question MUST understand how to deal with EWMH.

As for mouse/key bindings (especially key bindings) they’re a facet of the Xserver. Indeed, some WMs handle key bindings in a different way.

Since those two applications you’ve mentioned already do what you want – can you detail what it is they lack – and hence what it is you want?

The problem is that the code you want is often dependant on a lot of other functions – it can be (and would be) difficult to separate it out.

It’s not necessarily a stupid idea, Phil, I just need you to clarify a few things… :slight_smile:

– Thomas Adam

Of course, and MANY window managers do understand EWMH:
* blackbox >= 0.70
* icewm
* kwin (the default WM for KDE)
* metacity (the default WM for GNOME)
* openbox >= 3
* sawfish
* fvwm >= 2.5
* waimea
* pekwm
* enlightenment >= 0.16.6
* xfce >= 4
* fluxbox >= 0.9.6
* matchbox
* window maker >= 0.91

What makes FVWM the best WM is what those lack :slight_smile:.

Specifically, xbindkeys is just weak in comparison to the Key and Mouse (and Stroke, I want Stroke!) commands in FVWM. From a user’s perspective, the syntax for those commands is much easier to understand, but can accomplish so much more than xbindkeys. For example, the “context” parameter to Mouse/Key is not in xbindkeys. xbindkeys just can’t do everything listed in the section COMMANDS FOR MOUSE, KEY AND STROKE BINDINGS in the FVWM man pages.

Also, wmctrl is very limited. One simple example is that you cannot use wmctrl to go to the next desktop. You can tell it to go to a specific dekstop number, but not relative to the current one. Also, you only have four options when deciding what window to run a command on:

[list]Match a string against the title
Match the window ID
Make the user select the window
Use the currently active/focused window
This means you cannot, for example, run a command on the window which has the mouse over it.

The functions/features from FVWM that I think could be implemented for any WM using EWMH are in the following sections of the FVWM man page:

Specifically, what I do NOT care about is

Ultimately, my very first concern is whether any of this is feasible. Now, I understand that not all of these commands are feasible outside of FVWM, but I think a majority of them should be. So, what I would like to know is if the FVWM code for these commands is too integrated into and dependent on FVWM or if a lot of it just uses a standard EWMH interface, one that can be used with any WM.

  • Phil

Even for Key, Mouse, and Stroke?

/me pokes apberzerk and points to the Features’ guidelines point three.

tia :wink:

I’m aware of the list, thanks. My point is that not ALL window managers FULLY support EWMH – so it would be worth making a compatability list.

The stroke commands aren’t part of FVWM per se – the actual implemenation comes about from “libstroke” which are a set of libraries developed by someone else.

Indeed. Of course, it is possible to produce a separate program which would accomplish this.

Well, it’s only limited because it lacks the features – you’ll need to look lower down at the Xlib calls to make the more important features that you want.

That’s not a bad list.

You can, if you create a pipeline of commands starting with “xwininfo” and “grep”.

But then, any decent window manager should be able to do this. Have you seen the program “xwit”? You could use that as a basis/

It’s possible to do outside of FVWM, but then I wonder just how useful it would be. It would be a lot of work, too.

– Thomas Adam

I did not make a poll, because I did not think I could describe what I wanted very well. I figured it would confuse the hell out of people :slight_smile:

Personally, I think that Mouse/Key/Stroke bindings are not up to the window manager to implement. In Gnome, KDE, and Xfce, aren’t these things implemented in a separate program?

Also, I still disagree that I could do in wmctrl nearly half the things that FVWM can do with EWMH-related things. And even those things that can be done in wmctrl are much more complicated than using FVWM syntax.

Not sure if I agree with that one. The only window manager I know that does everything listed above (just FVWM) is not very easy to learn or user friendly. I would not expect metacity to be able to do these things, unless you really think it is possible to customize things that much and still have a user-friendly way of doing it.

Of course, but nobody has yet to build a good standalone application (and no, xstroke does not count), other than perhaps KHotkeys, which I used to use with other window managers, that can do strokes as well as FVWM.

As far as usefulness goes, think about the amount of work it would save other WM developers. It could mean moving towards a model in which window managers can be made up of chunks of individual applications, ones which are compatible with multiple window managers. Personally, I almost always prefer such a model when developing something.

  • Phil

Aha. xwit, wmctrl, and xbindkeys together might allow me to do what I want, though I would much rather prefer the easy syntax of FVWM.

  • Phil

Quite – not to mention that none of this is in FVWM’s best interests, either.

I diasgree – the reason why they’re part of the WM, is because the WM has to react to the actions performed. This of course begs the question how you’d make a standalone program that would work across different WMs, as they communicate differently (theoretically it’s possible, but all of the programs we have seen so far – wmctrl, for instance – affect windows which don’t care for the WM in the first place.)

Also, I still disagree that I could do in wmctrl nearly half the things that FVWM can do with EWMH-related things. And even those things that can be done in wmctrl are much more complicated than using FVWM syntax.

But then that’s a different issue – you can’t just try and take the good aspects of FVWM and try and apply them adhoc to some other WM, just because the learning-curve is somewhat steep.

Yes, that’s all well and good, but the issue still remains how the particular WM would be able to react to the events generated (and as I said above, the affect on windpws does not count.)

– Thomas Adam

Not seeing how that is possible.

The same way wmctrl works.

Well duh… Sorry, that just wasn’t a very useful comment, lol.