Fvwm... but not fvwm...

[apberzerk]

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

[thomasadam]

@apberzerk

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.

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.

@apberzerk

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).

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?

@apberzerk

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?

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.

@apberzerk

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

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

– Thomas Adam

[apberzerk]

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

Of course, and MANY window managers do understand EWMH:
[list]
* 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
[/list:u]

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?

What makes FVWM the best WM is what those lack .

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
[/list:u]
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:
[list]COMMANDS AFFECTING WINDOW MOVEMENT AND PLACEMENT
COMMANDS FOR FOCUS AND MOUSE MOVEMENT
COMMANDS CONTROLLING WINDOW STATE
CONDITIONAL COMMANDS
[/list:u]

Specifically, what I do NOT care about is
[list]THE STYLE COMMAND (CONTROLLING WINDOW STYLES)
MENUS
[/list:u]

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

[apberzerk]

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.

Even for Key, Mouse, and Stroke?

[theBlackDragon]

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

tia

[thomasadam]

@apberzerk

Of course, and MANY window managers do understand EWMH:

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.

@apberzerk

Specifically, xbindkeys is just weak in comparison to the Key and Mouse (and Stroke, I want Stroke!) commands in FVWM.

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.

@apberzerk

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

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

@apberzerk

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:

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.

@apberzerk

[list]Match a string against the title
Match the window ID
Make the user select the window
Use the currently active/focused window
[/list:u]

That’s not a bad list.

@apberzerk

This means you cannot, for example, run a command on the window which has the mouse over it.

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

@apberzerk

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:
[list]COMMANDS AFFECTING WINDOW MOVEMENT AND PLACEMENT
COMMANDS FOR FOCUS AND MOUSE MOVEMENT
COMMANDS CONTROLLING WINDOW STATE
CONDITIONAL COMMANDS
[/list:u]

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/

@apberzerk

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.

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

[apberzerk]

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

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.

But then, any decent window manager should be able to do this

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.

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.

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.

[apberzerk]

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

[apberzerk]

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

[thomasadam]

@apberzerk

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

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

@apberzerk

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?

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.

@apberzerk

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.

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.

@apberzerk

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.

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

[apberzerk]

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

Not seeing how that is possible.

[apberzerk]

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

The same way wmctrl works.

[apberzerk]

Well, it’s only limited because it lacks the features

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