Tux

...making Linux just a little more fun!

A window manager for Inkscape

Kat Tanaka Okopnik [kat at linuxgazette.net]


Mon, 2 Apr 2007 09:40:10 -0700

Hi gang -

After all this time editing the mailbag, I finally have an actual question for The Answer Gang. (I've searched the Net, and also asked at mailing lists for icewm and Inkscape.)

I've been using icewm as my window manager, but at this point I either need to find a way to configure it differently, or switch window managers altogether.

The basic problem is that icewm takes the input and processes it before Inkscape. (Input in this case is alt-click; there may be other input that is also an issue, but this is the one I'm aware of.) If I can, I'd like to bypass it, or alter the keypress combination that icewm is looking for.

The other possibility is finding a better window manager. As an interim measure, Ben found that ratpoison will at least ignore the alt-click issue. Unfortunately, ratpoison makes it harder to work in gimp. I know there are dozens if not hundreds of other window managers, but I'd really rather not test every single one of them.

When I was using ThatOther "OS", one of the things I used quite often was the IME (Input Method Editor), which allowed me to use a sequence of keystrokes to alter the way that my keyboard and mouse input was interpreted. Is there some equivalent that might be my answer here?

Hopeful,

-- 
Kat Tanaka Okopnik
Linux Gazette Mailbag Editor
kat@linuxgazette.net

Top    Back


Kapil Hari Paranjape [kapil at imsc.res.in]


Mon, 2 Apr 2007 11:08:11 -0700

Hello,

On Mon, 02 Apr 2007, Kat Tanaka Okopnik wrote:

> I've been using icewm as my window manager, but, at this point, I either
> need to find a way to configure it differently, or switch window
> managers altogether.

By a strange co-incidence I recently switched to "icewm" after "ion3" was declared experimental and not fit for "etch"!

> The basic problem is that icewm takes the input and processes it before
> Inkscape. (Input in this case is alt-click; there may be other input
> that is also an issue, but this is the one I'm aware of.) If I can, I'd
> like to bypass it, or alter the keypress combination that icewm is
> looking for.

The relevant file for "icewm" is $HOME/.icewm/preferences. The relevant options are below (defaults are commented out). Just change these to whatever you like.

	#  Mouse binding for window move
	# MouseWinMove="Alt+Pointer_Button1"
 
	#  Mouse binding for window resize
	# MouseWinSize="Alt+Pointer_Button3"
The "default" preferences file in /usr/share/icewm/preferences lists all the tweakable things in "icewm" --- and that turns out to be quite a lot. (The file location is for a Debian system).

> The other possibility is finding a better window manager.

As Thomas Adam will doubtless point out. The completely configurable window manager is "fvwm".

If you like to configure things from a menu interface, then you might wnat to check out xfce and friends. The associated window manager is quite configurable. It is the most lightweight of the "integrated desktop environment" type of systems.

Hope this helps,

Kapil. --


Top    Back


Thomas Adam [thomas.adam22 at gmail.com]


Tue, 3 Apr 2007 08:35:56 +0100

On Mon, 2 Apr 2007 09:40:10 -0700 Kat Tanaka Okopnik <kat@linuxgazette.net> wrote:

> The basic problem is that icewm takes the input and processes it
> before Inkscape. (Input in this case is alt-click; there may be other
> input that is also an issue, but this is the one I'm aware of.) If I
> can, I'd like to bypass it, or alter the keypress combination that
> icewm is looking for.

As explained here, key-bindings are always greedy with respect to the window manager:

http://linuxgazette.net/114/tag/3.html

I am sure you can tell IceWM to ignore it, but I wouldn't know how.

> The other possibility is finding a better window manager. As an
> interim measur, Ben found that ratpoison will at least ignore the
> alt-click issue. Unfortunately, ratpoison makes it harder to work in
> gimp. I know there are dozens if not hundreds of other window
> managers, but I'd really rather not test every single one of them.

The problem here is that almost all window managers will do what you want (I'd like to think. :P) but the question I'd like to ask you is what are your working habits within a windowing environment?

-- Thomas Adam


Top    Back


Kat Tanaka Okopnik [kat at linuxgazette.net]


Tue, 3 Apr 2007 20:04:03 -0700

On Tue, Apr 03, 2007 at 08:35:56AM +0100, Thomas Adam wrote:

> On Mon, 2 Apr 2007 09:40:10 -0700
> Kat Tanaka Okopnik <kat@linuxgazette.net> wrote:
> 
> > The basic problem is that icewm takes the input and processes it
> > before Inkscape. (Input in this case is alt-click; there may be other
> > input that is also an issue, but this is the one I'm aware of.) If I
> > can, I'd like to bypass it, or alter the keypress combination that
> > icewm is looking for.
> 
> As explained here, key-bindings are always greedy with respect to the
> window manager:
> 
> http://linuxgazette.net/114/tag/3.html
> 
> I am sure you can tell IceWM to ignore it, but I wouldn't know how.

via Thomas Holder, on the icewm mailing list -

in ~/.icewm/prefoverride:
  
ClientWindowMouseActions=0
> > The other possibility is finding a better window manager. As an
> > interim measur, Ben found that ratpoison will at least ignore the
> > alt-click issue. Unfortunately, ratpoison makes it harder to work in
> > gimp. I know there are dozens if not hundreds of other window
> > managers, but I'd really rather not test every single one of them.
> 
> The problem here is that almost all window managers will do what you
> want (I'd like to think.  :P) but the question I'd like to ask you is
> what are your working habits within a windowing environment?  

I don't really know what you're asking for, here.

I use Gimp a lot, which means that I have lots of small windows open, which should really function as a group. I often have Inkscape or Scribus open at the same time as Gimp. I usually also have a mutt session open, and at least one instance of mc.

I like being able to keystroke between apps, and to have an easy way of resizing windows. I don't like to have focus stolen just because I hovered over the wrong window. I'd really like to find something that will allow me to type in Japanese (and Russian) easily, but I think that's wandering offtopic for this particular thread.

I like being able to clear off (minimize) all the windows at once, to have a clean desktop and then re-maximize or restore just a few windows. I tend to have too many windows open at once. (I should probably use different er... desktops, is it, where one groups windows/apps?) It would be be fun to be able to tile all my windows, and then just enlarge one. I don't mind using a preferences file to change appearances, but I'd like readable documentation.

I don't know if that was not complete enough, too much information, or entirely the wrong sort of information. I'm reasonably certain that you'll tell me, though.

-- 
Kat Tanaka Okopnik
Linux Gazette Mailbag Editor
kat@linuxgazette.net

Top    Back


Thomas Adam [thomas.adam22 at gmail.com]


Wed, 4 Apr 2007 21:51:32 +0100

On Tue, Apr 03, 2007 at 08:04:03PM -0700, Kat Tanaka Okopnik wrote:

> I use Gimp a lot, which means that I have lots of small windows open,
> which should really function as a group. I often have Inkscape or
> Scribus open at the same time as Gimp. I usually also have a mutt
> session open, and at least one instance of mc.

Well, I can't speak for how IceWM works, because I have never used it properly, but, never wanting to miss a chance to exploit FVWM further, here's what I can say about how FVWM would do things. First, a little history...

There's a specification called the ICCCM (Inter-Client Communication Convention Manual, which attempts to outline how clients (which include not only applications, but the window manager itself) interoperate so that they both behave nicely. It's rather old, and parts of it are outdated, but that's by-the-by for this discussion.

The GIMP sets a property of itself (we call these XAtoms in XLib parlance), which are hints to the window manager that these windows are groups and are somehow related, but specifies nothing as to what the window manager should do in that situation. The hint is window_group which is part of the WM_HINTS struct.

It works like this: the main window (the leader of the group as it were) identfies itself. It does this by setting WM_CLIENT_LEADER which is typically its windowid (which is nothing more than a number assigned to a window each time it is mapped to the screen). Windows which then relate to this set themselves up to belong to the leader.

The question is then, how is this useful to you? Well it isn't -- not really, but it might be the case that other window managers make use of such a hint. FVWM happens to do so, but only in a limited capacity. Basically, what happens is that through the use of style lines (which tell FVWM how to treat various windows) you can tell it to either:

ScatterWindowGroups
or:

KeepWindowGroupsOnDesk
The former option is the default, since it could be confusing. Indeed, what would happen with 'KeepWindowGropsOnDesk' is that FVWM would then place all windows which belonged in a group "together", hence you might say:

Style Gimp KeepWindowGroupsOnDesk
Note that the word "Gimp" here is the class of the window [1] which ensures we don't have to write X number of lines for every possible Gimp window that you could use.

That's all very well, but I would have thought when you say "group" that's not what you meant, and I'd agree with you. ;) Neither of the style lines above allow for multiple commands to affect all Gimp windows at once say. And neither, perhaps would it allow proper placement of windows. So here's a few scenarios for you. Let's say you wanted all windows of the Gimp to start on a certain page:

Style Gimp StartsOnPage 1 1
You can also force it for a desk, too:

Style Gimp StartsOnDesk 2
If you wanted to, say, iconify all Gimp windows when you iconify one of them, you could bind something like:

DestroyFunc IconifyAllIfGimp
AddToFunc   IconifyAllIfGimp
+ I ThisWindow (Gimp) All (CurrentPage, !Iconic) Iconify
+ I TestRc (NoMatch) Iconify
Which first checks to ensure that if the window we're iconifying is a Gimp window, then to continue, iconifying all other Gimp windows if they're not iconic and on the current page. Otherwise, if it's not a Gimp window then just iconify it. Given that most people like to use the left-hand button of a window to do this, you would hence say:

Mouse 1 1 N IconifyAllIfGimp
One could hence extrapolate this further such that if one clicked on mouse button 2, say, on a window, that it then iconified all windows of that class on, say, the current page. Here's how to do that:

DestroyFunc IconifyAllClass
AddToFunc   IconifyAllClass
+ I All ($[w.class], CurrentPage, !Iconic) Iconify
+ I TestRc (NoMatch) Iconify
Note the change here -- we no longer need to check for the first instance of the window, since we don't care what the class of it is. Instead, we just instruct FVWM to take the current class of the window we're identifying and apply it for all windows thereof. This is what $[w.class] expands to.

> I like being able to keystroke between apps, and to have an easy way of
> resizing windows. I don't like to have focus stolen just because I
> hovered over the wrong window. I'd really like to find something that

Hmm, I am not sure what you mean by having focus stolen since that isn't playing nice at all. Key-bindings work just like mouse-bindings do. In FVWM there's kind of two types: those which are global (i.e, are captured by FVWM) and those which are bound to a specific window. As I have previously outlined [2] key/mouse bindings are greedy with respect to the window manager, but they can be mitigated by specifying to FVWM that a certain key-binding is to only apply to a specific window. To do this, you would say:

Key (some_window_name) F A C some_action
Where "some_action" is a command or function that FVWM understabds. Note that in the above this binding would only work if the application focused was called 'some_window_name'.

Conversely of course, it's desirable that in some instances FVWM shouldn't blindly be greedy with its key-grabbing tendencies, and in situations where they are bound window-specifically (as above) you would then say:

Key (some_window_name) F A C --
... which instructs FVWM to propagate the event down to the application rather than capturing it for itself.

> will allow me to type in Japanese (and Russian) easily, but I think
> that's wandering offtopic for this particular thread.

That's more for switching keyboard translations, no?

> I like being able to clear off (minimize) all the windows at once, to
> have a clean desktop and then re-maximize or restore just a few windows.

You've more or less seen how to do this in FVWM, and there's any number of ways you could do this. Something as simple as:

All (CurrentPage, !Iconic) Iconify
... will do just that, but restoring these windows is more problematic. The simple condition here of course is that it will allow you to select (through the application's icon) which windows to restore. You could also load FvwmIconMan, or use WinList, or FvwmWinList to do the window selection, but not the iconification.

As for restoring all windows once they've been iconified, you would need to mark them in some way, and then iconify them:

DestroyFunc IconifyAndRestore
AddToFunc   IconifyAndRestore
+ I All (CurrentPage, !Iconic) State 1
+ I All (State 1, CurrentPage, !Iconic) Iconify
The other half of the equation is to then restore them:

DestroyFunc Restore
AddToFunc   Restore
+ I All (State 1, Iconic, CurrentPage) Iconify 
+ I All (State 1) !State 1
You can of course combine to two functions to do both sets of operations if desired.

> I tend to have too many windows open at once. (I should probably use
> different er...desktops, is it, where one groups windows/apps?) It would

That's one solution, yes.

> be be fun to be able to tile all my windows, and then just enlarge one.
> I don't mind using a preferences file to change appearances, but I'd
> like readable documentation.

In terms of tiling, you could use the FvwmRearrange module to do this.

> I don't know if that was not complete enough, too much information, or
> entirely the wrong sort of information. I'm reasonably certain that
> you'll tell me, though.

I've given you loose snippets really in conjunction with ideas, the purpose of which is really just to demonstrate what can be done. I am happy to expand it further if it would be of help to you. I don't know, alas, whether IceWM is capable of doing anything suggested tus far.

-- Thomas Adam

[1] http://linuxgazette.net/127/adam.html [2] http://linuxgazette.net/114/tag/3.html

-- 
"He wants you back, he screams into the night air, like a fireman going
through a window that has no fire." -- Mike Myers, "This Poem Sucks".

Top    Back


Kat Tanaka Okopnik [kat at linuxgazette.net]


Thu, 5 Apr 2007 16:59:04 -0700

On Wed, Apr 04, 2007 at 09:51:32PM +0100, Thomas Adam wrote:

> On Tue, Apr 03, 2007 at 08:04:03PM -0700, Kat Tanaka Okopnik wrote:
> > I use Gimp a lot, which means that I have lots of small windows open,
> > which should really function as a group. I often have Inkscape or
> > Scribus open at the same time as Gimp. I usually also have a mutt
> > session open, and at least one instance of mc.
> 
> Well, I can't speak for how IceWM works because I have never used it
> properly.  But never wanting to miss a chance to exploit FVWM further,
> here's what I can say about how FVWM would do things.  But first a
> little history...

[...]

WOW. Thank you for all that! It's taken me some time to go through and digest what you wrote, and at the very least I now have a much better understanding of the mechanics of window management. When I'm ready to tackle customizing my window manager, I'll definitely refer back to this. For right now, I think my focus needs to be on the applications I'm busy acquiring facility with, rather than WM-tweaking.

(I have a much better appreciation of all your fvwm articles, now!)

I've elided all the parts where I didn't have anything to add except "oh, I think I see, thank you"; I've left in the bits where I had some clarification to add.

> > I like being able to keystroke between apps, and to have an easy way of
> > resizing windows. I don't like to have focus stolen just because I
> > hovered over the wrong window. I'd really like to find something that
> 
> Hmm, I am not sure what you mean by having focus stolen since that isn't
> playing nice at all.  

Focus dependent not on a mouseclick, but simply on hover. Feh. Something that you can set certain (IMHO 'rude') WMs to do, but it's generally not a default. I don't remember where I saw it as such, but I recall it driving me buggy - I do have a vague recollection that it was something that was changeable.

> > will allow me to type in Japanese (and Russian) easily, but I think
> > that's wandering offtopic for this particular thread.
> 
> That's more for switching keyboard translations, no?

Well...it could be, if what I wanted to do was remember keyboard mappings and switch keyboards, even if just "logically" (as opposed to physically. What I want to do instead is to be able to type in using a nifty and well-established kludge - typing in Western ASCII and having a bit of code that translates that all into whatever proper portion of the Unicode. In Wind0ws, it's an IME. I don't know yet what the equivalent is for Debian (or *nix in general), as I don't know what to look for.

> > I don't know if that was not complete enough, too much information, or
> > entirely the wrong sort of information. I'm reasonably certain that
> > you'll tell me, though.
> 
> I've given you loose snippets really in conjunction with ideas, the
> purpose of which is really just to demonstrate what can be done.  I am
> happy to expand it further if it would be of help to you.  I don't know,
> alas, whether IceWM is capable of doing anything suggested tus far.
[...]

> [1]  http://linuxgazette.net/127/adam.html
> [2]  http://linuxgazette.net/114/tag/3.html

It wouldn't surprise me if I could find a way to do this in IceWM. (I expected that fvwm was able to do this, my impression of it is that it's the emacs of wms. ;)

Thanks for the thorough answer, Thomas. I'll mull it over and let you know if I've got more specific requests. If we were in geographic proximity, I'd just offer to buy you a drink and make you dinner, and see if you'd sit down with me while I specified what I wanted, but that's a bit much to ask for over this narrow-bandwidth communication.

-- 
Kat Tanaka Okopnik
Linux Gazette Mailbag Editor
kat@linuxgazette.net

Top    Back


Karl-Heinz Herrmann [khh at khherrmann.de]


Fri, 6 Apr 2007 08:09:25 +0200

Hi,

On Thu, 5 Apr 2007 16:59:04 -0700 Kat Tanaka Okopnik <kat@linuxgazette.net> wrote:

> Focus dependent not on a mouseclick, but simply on hover. Feh.
> Something that you can set certain (IMHO 'rude') WMs to do, but it's
> generally not a default. I don't remember where I saw it as such, but I
> recall it driving me buggy - I do have a vague recollection that it was
> something that was changeable.

Just to comment on this as the tastes are different: The focus follows mouse/focus-under-mouse is one of the first things I switch on (fvwm, kde, gnome,..) and the why is this: I have two overlapping windows like a large [x]emacs window and a shell window. I want to transfer information from the shell in emacs. So I put the shell-window in front and the editor behind it and I want to type something in the editor while it stays behind the shell. Yes, I could get the same by telling the shell "alway stay on top" but then I've to set/reset that all the time. I combine this with 2 keys that bring a focused window to the front or pushes it back and another for iconify. Something I stole from the SUN keyboards which had real front/back keys.

My main gripe with focus-on-click is not that I have to click (even if I would forget that all the time) but I want to type in a partially visible window without it jumping in front of everything messing up a carefully arranged overlap of several windows.

BTW: gnome allows me to type in a partially hidden window -- but the moment I paste with the middle-mouse button it still jumps to the front. Is their a way to suppress that?

K.-H.


Top    Back


Kapil Hari Paranjape [kapil at imsc.res.in]


Fri, 6 Apr 2007 12:14:39 +0530

Hello,

On Fri, 06 Apr 2007, Karl-Heinz Herrmann wrote:

> BTW: GNOME allows me to type in a partially hidden window -- but the
> moment I paste with the middle-mouse button it still jumps to the
> front. Is their a way to suppress that? 

I think this is not a "feature" of GNOME but of the window manager (probably metacity).

Regards,

Kapil. --


Top    Back


Karl-Heinz Herrmann [khh at khherrmann.de]


Fri, 6 Apr 2007 10:07:06 +0200

Hi Kapil,

On Fri, 6 Apr 2007 12:14:39 +0530 Kapil Hari Paranjape <kapil@imsc.res.in> wrote:

> On Fri, 06 Apr 2007, Karl-Heinz Herrmann wrote:
> > BTW: GNOME allows me to type in a partially hidden window -- but the
> > moment I paste with the middle-mouse button it still jumps to the
> > front. Is their a way to suppress that? 
> 
> I think this is not a "feature" of GNOME but of the window manager
> (probably metacity).

good hint -- sure enough ps found an instance of metacity, and Google told be a little bit later that I would like to set /apps/metacity/general/raise_on_click to false. This leaves special-key-click and click-on-borders still active for raising, just as I would expect it to do.

I was using fvwm2 since kernel 2.0 -- then I got real fast CPUs, and KDE wasn't that bad an option, anymore. Some things one can get used to in KDE. Then the last install was an Ubuntu 6.10 with default GNOME and -- well it felt like a light version of KDE: I wasn't missing much apart from fine-grained window handling setting -- GNOME is not providing all the metacity options in the window-preferences. A Web site pointed me to gconf-edit -- which lists all options of metacity.

Learned something again -- thanks.

K.-H.


Top    Back


Thomas Adam [thomas.adam22 at gmail.com]


Fri, 6 Apr 2007 11:07:16 +0100

On Thu, Apr 05, 2007 at 04:59:04PM -0700, Kat Tanaka Okopnik wrote:

> I've elided all the parts where I didn't have anything to add except
> "oh, I think I see, thank you"; I've left in the bits where I had some
> clarification to add.

You're welcome.

> Focus dependent not on a mouseclick, but simply on hover. Feh.
> Something that you can set certain (IMHO 'rude') WMs to do, but it's
> generally not a default. I don't remember where I saw it as such, but I
> recall it driving me buggy - I do have a vague recollection that it was
> something that was changeable.

Ah, OK. What you're describing here is having a window raise above all others when the mouse hovers over it? That's typically called AutoRaise, and FVWM has a module which provides this functionality in the form of FvwmAuto. You'll be pleased to know it's not used by default. :)

> Well...it could be, if what I wanted to do was remember keyboard
> mappings and switch keyboards, even if just "logically" (as opposed to
> physically. What I want to do instead is to be able to type in using a
> nifty and well-established kludge - typing in Western ASCII and having a
> bit of code that translates that all into whatever proper portion of the
> Unicode. In Wind0ws, it's an IME. I don't know yet what the equivalent
> is for Debian (or *nix in general), as I don't know what to look for.

I'll get back to you -- you can do it, I've just forgotten how.

> It wouldn't surprise me if I could find a way to do this in IceWM. (I
> expected that fvwm was able to do this, my impression of it is that it's
> the emacs of wms. ;)

Heh, kind of. Just that it doesn't come with the kitchen sink or mindless bloat. ;)

Arlo Guthrie would have perhaps said: "You can get anything you want at Alice's Restaurant."

You might be able to do bits and pieces of what I've talked about in IceWM -- but for some of the more esoteric operations you might well have to use something like 'xwit' to help you; at least when Ben and I have discussed such things, that was the impression I got.

> Thanks for the thorough answer, Thomas. I'll mull it over and let you
> know if I've got more specific requests. If we were in geographic
> proximity, I'd just offer to buy you a drink and make you dinner, and
> see if you'd sit down with me while I specified what I wanted, but
> that's a bit much to ask for over this narrow-bandwidth communication.

Hmm, what's that phrase? "Aww, shucks"? :*) I don't mind creating something for you in the least -- would be interesting to detail it for you step-by-step so you can see the process of its creation. Regardless of geographic location (would you cook fish, only I love fish. :D), I more or less have done the same thing for Faber which spawned the Kiosk article in #128.

By all means, detail what it is you would like, take a few screenshots also if you think it would help, and I would be honoured to write something that FVWM could understand. I just don't want to try and move you away from something you're used to using though. :)

It'll give you some time, at least. I won't be back at a computer until Tuesday (public bank holiday).

-- Thomas Adam

-- 
"He wants you back, he screams into the night air, like a fireman going
through a window that has no fire." -- Mike Myers, "This Poem Sucks".

Top    Back