[dev] [wmii] Between tiling and floating
Hello! After using wmii on screens with three different sizes, I have realised that there is a feature that I'm missing on medium sized screens (around 17, say). Example: Very small screens require max mode anyway, and on very large screens the clients are usually large enough. But on a medium sized screen, when I have two clients opened (say on a LaTeX file and on the corresponding PDF file) in one column each, the columns are not large enough, and in the same column the clients are too large and not high enough. Of course I could toggle between the two clients in stack mode. This is not so bad, but viewing only the bars (sometimes above and sometimes below the focused one) is not so comfortable in my opinion. Thus I am wondering if it would be possible: 1) to increase dynamically the width of the focused column of a given percentage, say; 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. Probably the second solution is more difficult, if not impossible, since it is not pure tiling. But in my opinion, on the screen I'm working right now, it would be much more comfortable since it keeps unchanged all the clients in unfocused columns. Pro: - Keeps the advantages of tiling modes: no action is needed to resize the focused client, neither to reduce it when it looses the focus. - Adds some advantages of floating mode: -- The focused client has more space. -- All the other clients remain partly visible, hence can be seen in a glance, contrary to stack or max mode . Contra: - Useless for large and small screens. What is your opinion on this? Regards, LuX.
Re: [dev] [wmii] Between tiling and floating
Hi, On 07/26/2010 12:17 PM, LuX wrote: Thus I am wondering if it would be possible: 1) to increase dynamically the width of the focused column of a given percentage, say; 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. Probably the second solution is more difficult, if not impossible, since it is not pure tiling. But in my opinion, on the screen I'm working right now, it would be much more comfortable since it keeps unchanged all the clients in unfocused columns. Pro: - Keeps the advantages of tiling modes: no action is needed to resize the focused client, neither to reduce it when it looses the focus. - Adds some advantages of floating mode: -- The focused client has more space. -- All the other clients remain partly visible, hence can be seen in a glance, contrary to stack or max mode . You might try subtle [1]. Nice window manager which uses gravities to arrange clients. You can nicely overlay and overlap several clients using this feature. As a side effect this also avoids automatic resizes, which are a pain in dwm and wmii when you view large pdf files (e.g., poster drafts) in a viewer. It has some drawbacks compared to wmii of course. Its strict tagging behavior makes it hard to use project-based tags and views instead of application-based ones out of the box, for example. And you have to like Ruby. [1] http://subforge.org/wiki/subtle -- Thomas Dahms
Re: [dev] [wmii] Between tiling and floating
On Mon, Jul 26, 2010 at 3:17 AM, LuX lux.onthe...@free.fr wrote: I am wondering if it would be possible: 1) to increase dynamically the width of the focused column of a given percentage, say; You can do this now by reading /event and growing/shrinking the client in first column accordingly. 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. You can keep the overlapping client in the floating area and use wmii-2 style detaching (replace its tags with something, say |) and attaching (replace first client's tags in the, say |, view with current tag) actions to bring the overlapping client into your view when you need it. Here is an example from my wmiirc: http://github.com/sunaku/wmiirc/blob/master/control/action/detach.yaml http://github.com/sunaku/wmiirc/blob/master/control/keyboard/common/detach.yaml
[dev] [dwm] adding WM_WINDOW_ROLE rule
Hello dear dwm users, There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. Example : you want your firefox window tiled but not the download manager or not the preference client you could make a rule that catch the WM_WINDOW_ROLE - xprop WM_WINDOW_ROLE on the firefox windows and sub-windows -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = Preferences # this is preferences -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = browser # the main window -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = Manager # the download window Why is this so important? Because you can make more rules to specifig windows, I personally like to have the main browser window tiled but not the download window. This is also the same thing with pidgin, pidgin has a conversation window and a buddy list that have differents WM_WINDOW_ROLE. Of coure we could use the `title' rules but it's different on each locale you are using so it sucks as well. I would like to write a patch but for the moment I don't find the good function that handle WM_WINDOW_ROLE. With kind regards. -- Demelier David
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
Hi David, On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. Example : you want your firefox window tiled but not the download manager or not the preference client you could make a rule that catch the WM_WINDOW_ROLE - xprop WM_WINDOW_ROLE on the firefox windows and sub-windows -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = Preferences # this is preferences -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = browser # the main window -- xprop WM_WINDOW_ROLE -- WM_WINDOW_ROLE(STRING) = Manager # the download window Why is this so important? Because you can make more rules to specifig windows, I personally like to have the main browser window tiled but not the download window. This is also the same thing with pidgin, pidgin has a conversation window and a buddy list that have differents WM_WINDOW_ROLE. Of coure we could use the `title' rules but it's different on each locale you are using so it sucks as well. I would like to write a patch but for the moment I don't find the good function that handle WM_WINDOW_ROLE. I think the right thing to do would be to extend Rule and applyrules() with support for WM_WINDOW_ROLE. However I doubt that many client make actually use of WM_WINDOW_ROLE in a consistent way, which is why I believe there is no great benefit in doing so -- or in other words, yet another proof how hideous X has become ;) Cheers, Anselm
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: Hello dear dwm users, hi There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. dwm uses XGetClassHint() to retrieve the class and instance, and you can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on. I've attached a patch (with some dodgy casting) that works for me, but it's pretty useless. To have rules work with lots of arbitary WM_* rules would mean extending the code a lot for little gain - Iron (chromium clone) doesn't set WM_WINDOW_ROLE, for example, and nor does surf, nor vimprobable. tl;dr: However I doubt that many client make actually use of WM_WINDOW_ROLE in a consistent way, which is why I believe there is no great benefit in doing so -- or in other words, yet another proof how hideous X has become ;) Rob dwm-5.8.2-WM_WINDOW_ROLE.diff Description: plain/text
Re: [dev] [wmii] Between tiling and floating
Hi! On lun., juil. 26, 2010 at 11:58:26 -0700, Suraj Kurapati wrote: On Mon, Jul 26, 2010 at 3:17 AM, LuX lux.onthe...@free.fr wrote: 1) to increase dynamically the width of the focused column of a given percentage, say; You can do this now by reading /event and growing/shrinking the client in first column accordingly. Yes, I guess this should be possible. 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. You can keep the overlapping client in the floating area and use wmii-2 style detaching (replace its tags with something, say |) and attaching (replace first client's tags in the, say |, view with current tag) actions to bring the overlapping client into your view when you need it. ??? Here is an example from my wmiirc: http://github.com/sunaku/wmiirc/blob/master/control/action/detach.yaml http://github.com/sunaku/wmiirc/blob/master/control/keyboard/common/detach.yaml Thank you for the links, but honestly I don't understand them. I only have some basic notions of programming, in bash for example, but not in Ruby. I would prefer a solution not using yet-another-language. Is it possible to translate your hint in a simpler way? On lun., juil. 26, 2010 at 12:40:53 +0200, Thomas Dahms wrote: You might try subtle [..] And you have to like Ruby. Maybe I will give it a try, but I really like wmii hence I would prefer to keep with it if possible… and I don't know anything about Ruby. Thank you for your help, though. LuX.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Mon, Jul 26, 2010 at 11:09:22PM +0100, Anselm R Garbe wrote: I think the right thing to do would be to extend Rule and applyrules() with support for WM_WINDOW_ROLE. However I doubt that many client make actually use of WM_WINDOW_ROLE in a consistent way, which is why I believe there is no great benefit in doing so -- or in other words, yet another proof how hideous X has become ;) Has become? It was so from the start, and I'm really not certain it's possible for it to have become worse. There are certain depts of depravity in software that are impossible to surpass without resorting to Java. At any rate, WM_WINDOW_ROLE isn't meant to be used consistently, it's meant for session managers to allow clients to restore their individual windows. Personally, though, I'd just allow matching rules against arbitrary properties. -- Kris Maglione I speak to everyone in the same way, whether he is the garbage man or the president of the university. --Albert Einstein
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Mon, Jul 26, 2010 at 11:48:02PM +0100, Rob wrote:
On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote:
There is something that make me sad with dwm, there is a lack of role
rules for clients. I explain : clients have instance and name using
WM_CLASS, but there is also WM_WINDOW_ROLE which is really important
and useful.
dwm uses XGetClassHint() to retrieve the class and instance, and you
can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on.
Are you serious? I'm always in awe of Xlib's ludicrous
compliment of property getter/setter helper functions when none
of them would be necessary if it just had some remotely sensible
basic property accessor functions. wmii just does,
if(getprop_textlist(win, WM_CLASS, class))
...;
and
changeprop_textlist(win, WM_CLASS, STRING,
(char*[]){ foo, bar, 0 });
And it's just as simple, and a good deal cleaner.
--
Kris Maglione
Religion began when the first scoundrel met the first fool.
--Voltaire
Re: [dev] [wmii] Between tiling and floating
On Tue, Jul 27, 2010 at 01:20:59AM +0200, LuX wrote:
2) or otherwise to make the focused column overlap the others of a
given percentage while the others columns keep the same width.
You can keep the overlapping client in the floating area and use
wmii-2 style detaching (replace its tags with something, say |) and
attaching (replace first client's tags in the, say |, view with
current tag) actions to bring the overlapping client into your view
when you need it.
???
Indeed. That's why wmii doesn't do this anymore. :)
Here is an example from my wmiirc:
http://github.com/sunaku/wmiirc/blob/master/control/action/detach.yaml
http://github.com/sunaku/wmiirc/blob/master/control/keyboard/common/detach.yaml
Thank you for the links, but honestly I don't understand them. I only
have some basic notions of programming, in bash for example, but not
in Ruby. I would prefer a solution not using yet-another-language. Is
it possible to translate your hint in a simpler way?
On lun., juil. 26, 2010 at 12:40:53 +0200, Thomas Dahms wrote:
You might try subtle [..] And you have to like Ruby.
Maybe I will give it a try, but I really like wmii hence I would
prefer to keep with it if possible… and I don't know anything about
Ruby.
It could be, but it's a whole can of worms and I'm not sure it
suits your purpose. In the sh wmiirc, you'd probably do
something like,
master_width=800
master_tags='foo|bar'
...
Event AreaFocus
if wi_seltag | grep $master_tags /dev/null; then
export area=$1
width=$(wmiir read /tag/sel/index | awk '$2 == ENVIRON[area]
{ print $4; exit }')
delta=$(($master_width - $width))
if [ $area = 1 ]; then dir=right; else dir=left; done
wmiir write /tag/sel/ctl grow sel sel $dir ${width}px
fi
or something to that effect. Can't say that I like the idea
much myself, but to each his own.
--
Kris Maglione
Microsoft is not the answer. Microsoft is the question. NO is the
answer.
--Eric Naggum
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 26 Jul 2010, at 11:48, Rob wrote: On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: Hello dear dwm users, hi There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. Pardon me for ranting, but WM_WINDOW_ROLE looks like nothing more than brain-damage from freedesktop.org monks who had to reason away perfectly sound usage of WM_CLASS. I'm upset because this broke a window manager I got on with rather well, but I honestly wonder how close the reasoning behind this issue is to that of the 12th-century monks who wrote down, as a factual example for human life, that a badger when pursued by dogs would bite it's own balls off because it knew that's what the dogs were really after! I'm not kidding, monks really wrote that down. That and other things believed by medieval monks who could be very intellectual folk led me to the conclusion that human reason untrammelled by facts and practical sense will produce the stupidest beliefs. dwm uses XGetClassHint() to retrieve the class and instance, and you can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on. I've attached a patch (with some dodgy casting) that works for me, but it's pretty useless. To have rules work with lots of arbitary WM_* rules would mean extending the code a lot for little gain - Iron (chromium clone) doesn't set WM_WINDOW_ROLE, for example, and nor does surf, nor vimprobable. tl;dr: However I doubt that many client make actually use of WM_WINDOW_ROLE in a consistent way, which is why I believe there is no great benefit in doing so -- or in other words, yet another proof how hideous X has become ;) An idea crossed my mind, I don't know if it's worth anything. I thought of adding a pair of fields to dwm's window-matching array to match any X property set on a window. I don't know how the typing would work, perhaps it could involve a pointer to a union? Also it could be a nuisance to those with long window-matching lists. Rob dwm-5.8.2-WM_WINDOW_ROLE.diff
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 27 July 2010 00:35, Kris Maglione maglion...@gmail.com wrote: On Mon, Jul 26, 2010 at 11:48:02PM +0100, Rob wrote: On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. dwm uses XGetClassHint() to retrieve the class and instance, and you can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on. Are you serious? I just took a crack at patching dwm because I was bored. s/so it's not as trivial to add on/because X is quite shit/ dwm isn't meant to be wmii, so adding in wrappers would only increase the code size, when it's much more sane to simply test the window title, or if you can be bothered, mod+shift+tag. Rob
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Tue, Jul 27, 2010 at 12:53:12AM +0100, Ethan Grammatikidis wrote: On 26 Jul 2010, at 11:48, Rob wrote: There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. Pardon me for ranting, but WM_WINDOW_ROLE looks like nothing more than brain-damage from freedesktop.org monks who had to reason away perfectly sound usage of WM_CLASS. I'm upset because this broke a window manager I got on with rather well, but I honestly wonder how close the reasoning behind this issue is to that of the 12th-century monks who wrote down, as a factual example for human life, that a badger when pursued by dogs would bite it's own balls off because it knew that's what the dogs were really after! You would do well to indulge in some cursory research before opining. WM_WINDOW_ROLE predates the freedesktop project by quite a long time and serves an entirely different purpose from WM_CLASS. Nor could it be a freedesktop invention, since by policy they are all prefixed with _NET_. WM_WINDOW_ROLE is an old part of ICCCM that deals with session management, not window identification. -- Kris Maglione Deleted code is debugged code. --Jeff Sickel
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Tue, Jul 27, 2010 at 01:02:28AM +0100, Rob wrote: On 27 July 2010 00:35, Kris Maglione maglion...@gmail.com wrote: On Mon, Jul 26, 2010 at 11:48:02PM +0100, Rob wrote: On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: There is something that make me sad with dwm, there is a lack of role rules for clients. I explain : clients have instance and name using WM_CLASS, but there is also WM_WINDOW_ROLE which is really important and useful. dwm uses XGetClassHint() to retrieve the class and instance, and you can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on. Are you serious? I just took a crack at patching dwm because I was bored. s/so it's not as trivial to add on/because X is quite shit/ dwm isn't meant to be wmii, so adding in wrappers would only increase the code size, when it's much more sane to simply test the window title, or if you can be bothered, mod+shift+tag. I was trashing Xlib, not dwm. Regardless, the Xlib property get/set wrappers are in quite bad taste. -- Kris Maglione He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife. --Douglas Adams
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 27 July 2010 00:53, Ethan Grammatikidis eeke...@fastmail.fm wrote: ... An idea crossed my mind, I don't know if it's worth anything. I thought of adding a pair of fields to dwm's window-matching array to match any X property set on a window. I don't know how the typing would work, perhaps it could involve a pointer to a union? Also it could be a nuisance to those with long window-matching lists. Crossed my mind too, but I would have no use of it and flexible arrays inside structures are a pain, so I didn't bother. If you have any ideas, I'd be interested, though, purely implementation-wise. Rob
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Tue, Jul 27, 2010 at 01:11:05AM +0100, Rob wrote:
On 27 July 2010 00:53, Ethan Grammatikidis eeke...@fastmail.fm wrote:
...
An idea crossed my mind, I don't know if it's worth anything. I thought of
adding a pair of fields to dwm's window-matching array to match any X
property set on a window. I don't know how the typing would work, perhaps it
could involve a pointer to a union? Also it could be a nuisance to those
with long window-matching lists.
Crossed my mind too, but I would have no use of it and flexible arrays
inside structures are a pain, so I didn't bother.
If you have any ideas, I'd be interested, though, purely implementation-wise.
Not so much. There's quite easy if you allow C99, anyway.
typedef struct {
char *class;
char *regex;
int ord;
} Prop;
struct {
char *Rule;
RuleFn fn;
RuleArg arg;
} rules[] = {
{ (Rule[]){ {WM_CLASS, foo, 1}, {WM_NAME, bar}, {0}},
retag, { .s = baz } },
};
Or something to that effect. Although a macro to wrap up the
simple cases would probably help.
--
Kris Maglione
It is difficult to get a man to understand something when his salary
depends on his not understanding it.
--Upton Sinclair
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 27 July 2010 01:35, Kris Maglione maglion...@gmail.com wrote:
...
Not so much. There's quite easy if you allow C99, anyway.
typedef struct {
char *class;
char *regex;
int ord;
} Prop;
struct {
char *Rule;
RuleFn fn;
RuleArg arg;
} rules[] = {
{ (Rule[]){ {WM_CLASS, foo, 1}, {WM_NAME, bar}, {0}},
retag, { .s = baz } },
};
Or something to that effect. Although a macro to wrap up the simple cases
would probably help.
Oh yeah, forgot about C99 :D.
