On Sun, Jul 5, 2009 at 12:00 PM,
<address@hidden> wrote:
Send Stumpwm-devel mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/stumpwm-devel
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Stumpwm-devel digest..."
Today's Topics:
1. My stumpwm experience (none)
2. Re: My stumpwm experience (Michael Raskin)
3. Re: My stumpwm experience (Timur Sufiev)
----------------------------------------------------------------------
Message: 1
Date: Sun, 5 Jul 2009 17:11:06 +0400
From: none <address@hidden>
Subject: [STUMP] My stumpwm experience
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Hi.
I've used stumpwm for a while (version from git on Debian Lenny SBCL,
with nvidia xinerama like multiscreen), but found some inconveniences.
Maybe this will help you somehow.
There are some stumpwm aware apps. Evince can bypass wm tiling and
show window on another screen. Sometimes evince's new window can
appear placed not in any frame(like floating), also when such window
is focused, it will freeze all stumpwm hotkeys (changing focus is
possible with clicking, if this future is enabled). OOo 2.4 fullscreen
cause stumpwm crash. MPlayer with gtk gui segfault when it's window
is moved with mouse, also in floating it segfaults if it's build-in
fullscreen is activated. Thou maybe it's some bugs in apps, but
it's good if the wm will handle such cases correctly.
The idea of static tiling is good, but it's stumpwm realisation lacks
some features.
1. There is no way to cycle windows per frame basis, only the whole
group, so it's inconvenient if you want to emulate something tab's
like for several window in frame.
What about next-in-frame and prev-in-frame? I have those commands bound to shift+alt+left and right. Works great.
2. There is no way to share windows between several groups.
3. There is no way to manage popup window ( a) resize function, if their
default size is small, but there is a lot of free space in frame,
and b) manage them with parent window, so they will stay in one frame.
4. Make groups per xinerama screen.
This isn't a solution for xinerama, but I've set my xorg.conf to use two separate physical screens, so I have :0.0 and :0.1. The only downside to this is that if you have firefox running in one screen and you try to load a link from irc in the other screen, it throws an error saying that it's running somewhere, but can't use the application for the other screen. I prefer to manage each screen separately though.
As for floating (gnew-float):
5. No floating frames, only the whole group.
This doesn't bother me in the least.
6. The very poor floating handling, even no resize and focus
by default.
Cli:
7. It lacks utf8 support for filenames and some completion
preview (fast choosing) for dirs with many files.
It would be neat to have a setting like vi's "wildmenu" and "wildmode" commands for file completion.
~Egon