Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
2010/8/8 Kris Maglione maglion...@gmail.com: On Sun, Aug 08, 2010 at 09:36:24AM +0200, David DEMELIER wrote: It's so sad to see that suckless developers don't want to add 10 lines to the code to improve it just because *the developers* think it's useless. Maybe for people it's useless, but for others it can be useful. Sad. Don't get pissy. 10 lines here and there adds up. So does a feature here and there, especially when it would likely be used by so few. If you want it and you can't convince the developers that it's worthwhile, maintain a patch. That's how it works here. If you don't like it, you're welcome to go somewhere else. -- Kris Maglione The tragedy of modern war is not so much that young men die but that they die fighting each other, instead of their real enemies back home in the capitals. --Edward Abbey I agree for an optional patch if it's possible. -- Demelier David
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
2010/7/27 Anselm R Garbe garb...@gmail.com: 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 It's so sad to see that suckless developers don't want to add 10 lines to the code to improve it just because *the developers* think it's useless. Maybe for people it's useless, but for others it can be useful. Sad. Kind regards. -- Demelier David
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
Refuse to add code is sad but allright. Refuse to remove code would be real problem. Dne 8.8.2010 9:36 David DEMELIER demelier.da...@gmail.com napsal/a: 2010/7/27 Anselm R Garbe garb...@gmail.com: Hi David, On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote: There is ... It's so sad to see that suckless developers don't want to add 10 lines to the code to improve it just because *the developers* think it's useless. Maybe for people it's useless, but for others it can be useful. Sad. Kind regards. -- Demelier David
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Sun, Aug 08, 2010 at 09:36:24AM +0200, David DEMELIER wrote: It's so sad to see that suckless developers don't want to add 10 lines to the code to improve it just because *the developers* think it's useless. Maybe for people it's useless, but for others it can be useful. Sad. Don't get pissy. 10 lines here and there adds up. So does a feature here and there, especially when it would likely be used by so few. If you want it and you can't convince the developers that it's worthwhile, maintain a patch. That's how it works here. If you don't like it, you're welcome to go somewhere else. -- Kris Maglione The tragedy of modern war is not so much that young men die but that they die fighting each other, instead of their real enemies back home in the capitals. --Edward Abbey
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. Are you sure, or am I just being stupid again? I am writing this mail in dillo2, a fltk browser. And I possess no fontconfig. t...@box:~$ fontconfig sh: fontconfig: not found
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Sat, Jul 31, 2010 at 01:46:02PM +0300, hiro wrote: Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. Are you sure, or am I just being stupid again? I am writing this mail in dillo2, a fltk browser. And I possess no fontconfig. t...@box:~$ fontconfig sh: fontconfig: not found t...@box:~$ fc-list -- Kris Maglione Fashion is something barbarous, for it produces innovation without reason and imitation without benefit. --George Santayana
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 27 Jul 2010, at 1:03, Kris Maglione wrote: 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. I guess I should have focussed my rant differently, but one thing which does not predate fd.o is the practice of setting both class and name (in WM_CLASS) to the same for every window in the application. I'm fairly sure when this practice first caught my attention I looked it up only to read a ridiculous mandate decreeing class and name *must* be set the same (except for capitalisation) on every top-level window of an application. I'm almost certain the same mandate decreed WM_WINDOW_ROLE to be the thing to use to distinguish between different windows of the same application. Some cursory research seems not to be enough to find about anything how to use WM_CLASS etc, or at least 20 minutes of searching turned up nothing for me. -- Kris Maglione Deleted code is debugged code. --Jeff Sickel
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: On Tue, Jul 27, 2010 at 1:29 AM, Kris Maglione maglion...@gmail.com wrote: 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. I think somehow X managed to surpass its own hideousness without resorting to Java thanks to things like the use of XML by fontconfig, and the auto*hell-ization of the whole X.org distribution. I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. And, as for autohell, well, bad as it is, I'm really not sure that it's worse than imake. Indeed. I've not heard anything good about imake, and back when autotools was considerably less mature than it is now I only ever came across one or two packages outside X which preferred imake to autotools.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Sat, Jul 31, 2010 at 02:12:39AM +0100, Ethan Grammatikidis wrote: On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. -- Kris Maglione Insane people are always sure that they are fine. It is only the sane people who are willing to admit that they are crazy. --Nora Ephron
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On 31 Jul 2010, at 3:33, Kris Maglione wrote: On Sat, Jul 31, 2010 at 02:12:39AM +0100, Ethan Grammatikidis wrote: On 28 Jul 2010, at 2:24, Kris Maglione wrote: On Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. Can you build or run the X server without fontconfig? I haven't tried in years, but if I remember right the one time I tried, it wouldn't work. Yes, you can. fontconfig is purely a client-side library. On the other hand, Xft requires it, and therefore so does everything built on GTK, Qt, FLTK, or Java. More sinister, ghostscript also requires it, and so does xetex (most distressingly). It will be a bad day when I meet Kieth Packard. Must have been the libraries that wouldn't build, but I'm sure it was core X.org. I don't think it was Xft, but if it was then some essential lib had deps on Xft I didn't expect.
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
2010/7/27 Rob robpill...@gmail.com: 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. Thanks for your work, but there is many applications that also set it. pidgin, gajim, firefox, gimp ... 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 -- Demelier David
Re: [dev] [dwm] adding WM_WINDOW_ROLE rule
On Tue, Jul 27, 2010 at 1:29 AM, Kris Maglione maglion...@gmail.com wrote: 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. I think somehow X managed to surpass its own hideousness without resorting to Java thanks to things like the use of XML by fontconfig, and the auto*hell-ization of the whole X.org distribution. uriel 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 Wed, Jul 28, 2010 at 11:55:14AM +0200, Uriel wrote: On Tue, Jul 27, 2010 at 1:29 AM, Kris Maglione maglion...@gmail.com wrote: 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. I think somehow X managed to surpass its own hideousness without resorting to Java thanks to things like the use of XML by fontconfig, and the auto*hell-ization of the whole X.org distribution. I have to admit that I don't make a strong distinction between XML and Java, but fontconfig really isn't X. It's just an external library like anything else. And, as for autohell, well, bad as it is, I'm really not sure that it's worse than imake. -- Kris Maglione One does well to put on gloves when reading the New Testament. The proximity of so much uncleanliness almost forces one to do this. --Friedrich Nietzsche
[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] [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] [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.
