Re: [dwm] dwm: request to discuss
2008/8/29, Anselm R Garbe [EMAIL PROTECTED]: I like simplicity. I like simple applications. But few LOCs don't mean that application is simple. It means only that it has few LOCs. I only argue that few LOCs is a good indicator of simplicty, not the only one, though. I see. To be simple application must be simple in use, simple in extensioning, simple in hacking, simple in configurating. In my opinion dwm as it is meets these ideals quite well. No doubt. Otherwise dwm would be different. Why you trying to escape just two optional operations of nav.? Let's be honest, it's not two operations in the end. Introducing workspaces means, that you need more than just navigation, you also need moving clients between workspaces, etc. Of course, I may be wrong. But for now I see just two ops: next and previous workspace. You don't need to move somehow a client between workspaces: you just need to use already exist ops---tag and untag. Workspace is just a set of settings such as selected tags, layout and layout parameters. You have such tags: www, mail, irc, im, dev. The most time you spend on developing something. But from time to time you want to check irc and mail, maybe serf smth. And all the time you want to see your im client. What you do? Untag www, mail, irc; tag dev; change layout; change order of windows... ouch. No no -- in this situation you define your im client being floating and tagged with all tags (~0). To check from time to time irc and mail you just toggle your irc and mail tags into the view -- you could bind a special key to do this -- and for toggling between this you can use Alt-Tab afterwards. The order of windows will be preserved if you Alt-Tab btw, as long as you do not perform zoom(). I understand all this as a workaround. Too much actions for me. I have already written about it: Mod+Tab switches between _two_ sets of tags. Just two and just tags. Binding a key via config.h makes it hardcoded, not dynamic. d in dwm stands for dynamic (; Now you have two workspaces/desktops: one for the Internet (irc, im, www, mail), another one for a work (dev, im). The first has rstack layout with corresponding master width and windows order. The second has bstack layout with an editor in master area and two terminals on the bottom: one is tagged as dev (for output, debug...), another one is tagged as im. Now you use just one key to change between these desktops. Each one is comfortable for its purposes. No need to rearrange windows and so on. Well you don't need a workspace for this. What you want is remembering the layout in use on a tagset basis. That's easy to patch in. It remembers just a layout? If yes, then again it is not what I want. Ok, you have two sets of tags and switch between them with a help of Mod+Tab and that patch makes dwm to remember layout per tags sets, right? Does it remember master width per sets? -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
2008/8/30 Maxim Vuets [EMAIL PROTECTED]: 2008/8/29, yy [EMAIL PROTECTED]: Just to show you (and all the people who come here asking for workspaces from time to time) I have attached a config.h with a workspaces implementation. It hasn't been tested very much, but I think it works. Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with the mouse wheel on the tags. Cool patch. Thank you. Almost that I want (: Add to the wiki. -- Hoc est simplicissimum! maxim.vuets.name http://www.suckless.org:8000/dwm/patches/workspaces.html There was a bug in the config.h that I attached to my other message, it was not setting mfact to 0 for non tiled layouts. -- - yiyus || JGL .
Re: [dwm] dwm: request to discuss
On Sat, Aug 30, 2008 at 2:11 AM, Maxim Vuets [EMAIL PROTECTED] wrote: 2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]: Apache httpd with threads and mod_*.so, PAM... So every You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less Hmmm, I think threads make it just easier to write software that does several things concurrently. Makes easier to write? Oh man, I think you just have not ever write and debug real multi-threaded application (; Just for a note: yes, .so for dwm is evil. I've already said it. But unix-way IPC---looks not so bad, I think. Do you mean pipes or sockets? Pipe are definitely suckless. But this whole UNIX socket API sucks really. Yes, I meant pipes. I like pipes. Cannot understand why socket API sucks. -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
On 8/30/08, Chris Monson [EMAIL PROTECTED] wrote: On Sat, Aug 30, 2008 at 2:11 AM, Maxim Vuets [EMAIL PROTECTED] wrote: 2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]: You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less try thttpd nhttpd hiawatha
Re: [dwm] dwm: request to discuss
If you are looking for a non-app-server http server, look for 'publicfile'. 2008/8/30 Antoni Grzymala [EMAIL PROTECTED] Chris Monson dixit (2008-08-30, 13:55): You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. (: propose something less sucker, please. I'll take a look. lighttpd - definitely sucks less Seems to be a bit of an urban legend. Both resource-wise and code-wise. -- [a] -- Cheers, Filippo
Re: [dwm] dwm: request to discuss
2008/8/28, Alexander Polakov [EMAIL PROTECTED]: What you do? Press Alt-o which brings my IM-client to me. Then press alt-o to hide it back. That is not what I meant. Such title bars bring a possibility to manage windows w/o keyboard (; 2 paragraphs before you said mouse is not important. It is just a counterexample. Mouse is not important for me. -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
2008/8/29, Donald Chai [EMAIL PROTECTED]: I think that mouse is not really important for dwm status bar. So we can neglect of such feedback. I can not agree we you that shared libraries and some ABI is so bad. But agree that it is too heavy for such program as dwm. It is useless here. On the other hand, extending via code patching is wierd. Especially when you need to apply more than one patch. You might enjoy reading this interview with Don Knuth: http://www.informit.com/articles/article.aspx?p=1193856 Basically, re-editable code is better than reusable code (to him). Thanks a lot for the link, I'll look it a bit later. My 5 cents (: Knuth is a mathematician. All that theory is good, but it is not always applicable in practice. IIRC, Eric Raymond says that binary RPC is evil, threads are evil etc. But look: we are using Apache httpd with threads and mod_*.so, PAM... So every technical approach is good and useful in some exact context of its usage. Threads are evil for dwm (: but is good for highload network server. And so on. Just for a note: yes, .so for dwm is evil. I've already said it. But unix-way IPC---looks not so bad, I think. What version of dwm are you using? Tip. dwm has had two workspaces/desktops since I've been using it (admittedly not very long). Press MOD-Tab to switch between them. Hm, right. In fact it is just previous set of tags. Not actualy that I want to get. And does not work with more than two desktops. -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
2008/8/29, Matthias-Christian Ott [EMAIL PROTECTED]: If you want to seperate dwm and status bar you have to come up with a practical protocol. Definitely! (: Assumed that dwm still manages the tags and status bar is just responsible for displaying the data, I propose (not perfect, just to give you an idea): Thanks. I'll look it closer when will decide to start some real work. -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
2008/8/29, yy [EMAIL PROTECTED]: You don't need any changes in dwm.c to achieve this functionality. You just have to define your keys your way. e.g. (not tested) : ... This way you could chose workspaces with q, w,... You could also write a little function to set this parameters and call arrange just once to avoid flickering, or use a variable to be able to cycle through them or change the values per workspace. I just want to show that you can add all this without any complication. Yes, nice idea, thank you! But as I see all parameters are hardcoded. I cannot remove some tag from some desktop... Em, I can, but it will return on the next switch. Again, have a look at my config.h in the customisation section if you want an example. Please poke me in your config.h (: -- Hoc est simplicissimum! maxim.vuets.name
Re: [dwm] dwm: request to discuss
Maxim Vuets wrote: 2008/8/29, Donald Chai [EMAIL PROTECTED]: I think that mouse is not really important for dwm status bar. So we can neglect of such feedback. I can not agree we you that shared libraries and some ABI is so bad. But agree that it is too heavy for such program as dwm. It is useless here. On the other hand, extending via code patching is wierd. Especially when you need to apply more than one patch. You might enjoy reading this interview with Don Knuth: http://www.informit.com/articles/article.aspx?p=1193856 Basically, re-editable code is better than reusable code (to him). Thanks a lot for the link, I'll look it a bit later. My 5 cents (: Knuth is a mathematician. All that theory is good, but it is not always applicable in practice. IIRC, Eric Raymond says that binary RPC is evil, threads are evil etc. But look: we are using Apache httpd with threads and mod_*.so, PAM... So every You are using Apache? Shame on you ;). Seriously Apache is definitively not suckless. technical approach is good and useful in some exact context of its usage. Threads are evil for dwm (: but is good for highload network server. And so on. Hmmm, I think threads make it just easier to write software that does several things concurrently. AFAIR Plan 9 has good examples were this kind of concurrency is used in a nice way. Just for a note: yes, .so for dwm is evil. I've already said it. But unix-way IPC---looks not so bad, I think. Do you mean pipes or sockets? Pipe are definitely suckless. But this whole UNIX socket API sucks really. What version of dwm are you using? Tip. dwm has had two workspaces/desktops since I've been using it (admittedly not very long). Press MOD-Tab to switch between them. Hm, right. In fact it is just previous set of tags. Not actualy that I want to get. And does not work with more than two desktops. Regards Matthias-Christian
Re: [dwm] dwm: request to discuss
2008/8/28 Maxim Vuets [EMAIL PROTECTED]: 2008/8/28, Anselm R Garbe [EMAIL PROTECTED]: The reason for the built-in status bar is simplicity. In theory it would be possible to externalize it, but then you would end up with adding some kind of command interface to dwm to aim the mouse interaction from the bar. In the end externalizing the bar won't really be a benefit, because the modularized result will be more complex, and dwm might be more complex. Even if one considers a bar externalization as a shared object, which is loadable, this would introduce the need of a plugin API, which won't provide the same level of flexibility as hooking into the source code, which allows you everything. I like simplicity. I like simple applications. But few LOCs don't mean that application is simple. It means only that it has few LOCs. I only argue that few LOCs is a good indicator of simplicty, not the only one, though. To be simple application must be simple in use, simple in extensioning, simple in hacking, simple in configurating. In my opinion dwm as it is meets these ideals quite well. I think that mouse is not really important for dwm status bar. So we can neglect of such feedback. I use the mouse quite often in dwm, so for me it is. It feels more natural to me to right click a tag, than performing the toggletag() keybinding for instance. I can not agree we you that shared libraries and some ABI is so bad. Well, there are use cases for this design. However, the Unix philosophy is about fork() and pipe(), so there is no need to implement inter-process communication using libdl, especially not in simple software. If dmenu won't read from stdin and write to stdout, it might be a monster project already with a fully-fledged library on top which might be integrated into many programs using dlopen(). However dmenu reads from stdin adn writs to stdout -- this will make it survive even longer than most UI toolkit apps. It's the nature of dwm since the first minute to not follow the workspace model. Actually I use the tagging concept with at least two tags at a time quite frequently. Adding a layer onto tags might suit you, but I doubt I will accept such a change in mainstream dwm, since it adds at least two operations of navigation. Why you trying to escape just two optional operations of nav.? Let's be honest, it's not two operations in the end. Introducing workspaces means, that you need more than just navigation, you also need moving clients between workspaces, etc. I'll try to explain my vision on an expamle. You have such tags: www, mail, irc, im, dev. The most time you spend on developing something. But from time to time you want to check irc and mail, maybe serf smth. And all the time you want to see your im client. What you do? Untag www, mail, irc; tag dev; change layout; change order of windows... ouch. No no -- in this situation you define your im client being floating and tagged with all tags (~0). To check from time to time irc and mail you just toggle your irc and mail tags into the view -- you could bind a special key to do this -- and for toggling between this you can use Alt-Tab afterwards. The order of windows will be preserved if you Alt-Tab btw, as long as you do not perform zoom(). Now you have two workspaces/desktops: one for the Internet (irc, im, www, mail), another one for a work (dev, im). The first has rstack layout with corresponding master width and windows order. The second has bstack layout with an editor in master area and two terminals on the bottom: one is tagged as dev (for output, debug...), another one is tagged as im. Now you use just one key to change between these desktops. Each one is comfortable for its purposes. No need to rearrange windows and so on. Well you don't need a workspace for this. What you want is remembering the layout in use on a tagset basis. That's easy to patch in. We had small title bars on top of unfocused windows a while ago, but I removed this for simplicity reasons and because it is obvious what kind of client is associated in a tiled environment ;) Look, one of the reasons why you want to keep status bar is that it's more simple to interact with it via mouse. It uses only mouse. But there is no way to manage windows using only mouse, because you need to hold some meta key, you know. Such title bars bring a possibility to manage windows w/o keyboard (; See the other mails for details regarding mouse usage, which isn't poor in dwm. My main reason for the dwm bar is keeping track of the tags and reading the status info occasionally. I don't care that much about the client title most of the time. Kind regards, --Anselm
Re: [dwm] dwm: request to discuss
On Fri, Aug 29, 2008 at 10:40 AM, Anselm R Garbe [EMAIL PROTECTED] wrote: I think that mouse is not really important for dwm status bar. So we can neglect of such feedback. I use the mouse quite often in dwm, so for me it is. It feels more natural to me to right click a tag, than performing the toggletag() keybinding for instance. I'll second that. Mouse interaction is the reason I switched from xmonad to dwm. I would probably switch to something else if it were removed (or hack it back in myself). -- David
Re: [dwm] dwm: request to discuss
Just to show you (and all the people who come here asking for workspaces from time to time) I have attached a config.h with a workspaces implementation. It hasn't been tested very much, but I think it works. Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with the mouse wheel on the tags. But as I have told in my previous message in this thread I think this is over complicated. You will probably have problems to remember what the different workspaces are (since you will probably modify it), and you will finish changing your tags and layout instead of going to another workspace. Anyway, I think it is a good reference to have in the ml. If somebody uses it, please report me any problems because I'm going to add it to the wiki (maybe this weekend). Though I won't maintain it for future releases, as I told IMO this is not a good idea, but it is a good example of how easy is to extend dwm. rgds, -- - yiyus || JGL . config.h Description: Binary data
Re: [dwm] dwm: request to discuss
Hi there, 2008/8/27 Maxim Vuets [EMAIL PROTECTED]: So. What I want to know is that why dwm uses built-in status bar, when even such heavy WM as metacity does not has such one? The problems I see: dwm somehow needs to pass current tags status. Not a problem in fact. And not a requirement, is not it? Also dwm must do a padding to make another bar to fit. (Not sure.) Advantages: a lot. You can any status bar you want. (We can write our own suckless status bar.) (; Unix-way, because WM will just manage windows, but not shows some additional info. (Recall xmonad---it does not has status bar, only via extensions.) No body will annoy about that stupid squares. *joking* The reason for the built-in status bar is simplicity. In theory it would be possible to externalize it, but then you would end up with adding some kind of command interface to dwm to aim the mouse interaction from the bar. In the end externalizing the bar won't really be a benefit, because the modularized result will be more complex, and dwm might be more complex. Even if one considers a bar externalization as a shared object, which is loadable, this would introduce the need of a plugin API, which won't provide the same level of flexibility as hooking into the source code, which allows you everything. Next, tags. Really cool idea for sure. But let's be honest: how much of us use them as tags, not as workspaces? I think not much. The most common usage would be the kinda this: you have tags www, devel, gfx, movie and so on. On the first one you keep browser, mail reader. On the second one---vim or emacs, terminal or two... Etc. From time to time you are switching among them. This way is called named workspaces. No? I don't propose to get rid of tags, no! I propose to introduce workspaces in addition to tags. It will be just sets which keep current layout and selected tags. That's all! I want to use some layout scheme to one set of windows and another layout to another set. dwm cannot do it. awesome can (exactly for 2.x, don't know about 3.x). But it is broken---it tryies to use tags (yes, they are still tags) as workspaces. It remembers layout per tag. It's the nature of dwm since the first minute to not follow the workspace model. Actually I use the tagging concept with at least two tags at a time quite frequently. Adding a layer onto tags might suit you, but I doubt I will accept such a change in mainstream dwm, since it adds at least two operations of navigation. Also small title for each window may be usufull. (Especilly, if status bar will be separated to 3rd-party app.) But not sure. Seems that it does not conform to the dwm philosophy. We had small title bars on top of unfocused windows a while ago, but I removed this for simplicity reasons and because it is obvious what kind of client is associated in a tiled environment ;) Kind regards, --Anselm
Re: [dwm] dwm: request to discuss
The most time you spend on developing something. But from time to time you want to check irc and mail, maybe serf smth. And all the time you want to see your im client. What you do? Press Alt-o which brings my IM-client to me. Then press alt-o to hide it back. Such title bars bring a possibility to manage windows w/o keyboard (; 2 paragraphs before you said mouse is not important.
Re: [dwm] dwm: request to discuss
On Aug 28, 2008, at 1:12 PM, Maxim Vuets wrote:
The reason for the built-in status bar is simplicity. In theory it
would be
possible to externalize it, but then you would end up with adding
some
kind of command interface to dwm to aim the mouse interaction from
the bar. In the end externalizing the bar won't really be a
benefit, because
the modularized result will be more complex, and dwm might be
more complex.
Even if one considers a bar externalization as a shared object,
which is
loadable, this would introduce the need of a plugin API, which
won't provide
the same level of flexibility as hooking into the source code,
which allows
you everything.
I like simplicity. I like simple applications. But few LOCs don't
mean that
application is simple. It means only that it has few LOCs.
To be simple application must be simple in use, simple in
extensioning,
simple in hacking, simple in configurating. Application can be small
but sucks and vice versa.
I think that mouse is not really important for dwm status bar.
So we can neglect of such feedback.
I can not agree we you that shared libraries and some ABI is so bad.
But agree that it is too heavy for such program as dwm. It is useless
here. On the other hand, extending via code patching is wierd.
Especially when you need to apply more than one patch.
You might enjoy reading this interview with Don Knuth:
http://www.informit.com/articles/article.aspx?p=1193856
Basically, re-editable code is better than reusable code (to him).
In any case, an application can be: simple to extend, simple to hack,
simple to configure (can configure without patching/recompiling).
Pick two.
Why you trying to escape just two optional operations of nav.?
I'll try to explain my vision on an expamle.
You have such tags: www, mail, irc, im, dev.
The most time you spend on developing something.
But from time to time you want to check irc and mail, maybe serf smth.
And all the time you want to see your im client.
What you do? Untag www, mail, irc; tag dev; change layout; change
order of windows... ouch.
Now you have two workspaces/desktops: one for the Internet (irc, im,
www, mail), another one for a work (dev, im). The first has rstack
layout
with corresponding master width and windows order. The second has
bstack layout with an editor in master area and two terminals on the
bottom: one is tagged as dev (for output, debug...), another one is
tagged as im. Now you use just one key to change between these
desktops. Each one is comfortable for its purposes.
No need to rearrange windows and so on.
What version of dwm are you using?
dwm has had two workspaces/desktops since I've been using it
(admittedly not very long). Press MOD-Tab to switch between them.
This patch to hg tip will get you one layout per workspace:
--- a/dwm.c Wed Aug 27 12:52:44 2008 +0100
+++ b/dwm.c Thu Aug 28 14:06:07 2008 -0700
@@ -1280,8 +1280,6 @@
void
setlayout(const Arg *arg) {
- if(!arg || !arg-v || arg-v != lt[sellt])
- sellt ^= 1;
if(arg arg-v)
lt[sellt] = (Layout *)arg-v;
if(sel)
@@ -1657,7 +1655,7 @@
view(const Arg *arg) {
if((arg-ui TAGMASK) == tagset[seltags])
return;
- seltags ^= 1; /* toggle sel tagset */
+ sellt = seltags ^= 1; /* toggle sel tagset */
if(arg-ui TAGMASK)
tagset[seltags] = arg-ui TAGMASK;
clearurgent();
Re: [dwm] dwm: request to discuss
Maxim Vuets wrote: 2008/8/28, Matthias-Christian Ott [EMAIL PROTECTED]: I don't propose to get rid of tags, no! I propose to introduce workspaces in addition to tags. It will be just sets which keep current layout and selected tags. That's all! +1 That makes sense to me, but where do you want to place the workspace list? It is not strongly neceserry. If status bar will be separate application, it is not care of dwm. If not---I see one nice place: before tags list. But not list and just a name of the current workspace. If you want to seperate dwm and status bar you have to come up with a practical protocol. Assumed that dwm still manages the tags and status bar is just responsible for displaying the data, I propose (not perfect, just to give you an idea): :s ntag n was selected :d ntag n was deselected :a ntag n contains windows (litlle square) :l llayout l selected :t sset window title to s :f current window is floating Anyhow sourcing out the status bar that will probably make dwm more complex than the monolithic version. I really favour modularity, unix philsophy and simplicty, but I think in this case there are good enough reasons to break these rules, if you think in terms of LOC and complexity. I want to use some layout scheme to one set of windows and another layout to another set. dwm cannot do it. awesome can (exactly for 2.x, don't know about 3.x). But it is broken---it tryies to use tags (yes, they are still tags) as workspaces. It remembers layout per tag. +1 Another nice feature would be a workspace deck or tag deck. This way multiple tags or workspaces can be overlay each other on multiple layers. I don't if this really practically relevant. If I understand you correctly, I don't see practical usage of such deck. Your example? I have to admit that ehe overlay makes just some sense with floating windows, otherwise it's just circling through workspaces/tags. Regards Matthias-Christian
Re: [dwm] dwm: request to discuss
2008/8/28 Maxim Vuets [EMAIL PROTECTED]:
I think that mouse is not really important for dwm status bar.
Well, I think it is. I use dwm exclusively with the mouse without any
changes to dwm.c (have a look at the customisation/customfunctions
section in the wiki to see my config.h)
Why you trying to escape just two optional operations of nav.?
I'll try to explain my vision on an expamle.
You have such tags: www, mail, irc, im, dev.
The most time you spend on developing something.
But from time to time you want to check irc and mail, maybe serf smth.
And all the time you want to see your im client.
What you do? Untag www, mail, irc; tag dev; change layout; change
order of windows... ouch.
Now you have two workspaces/desktops: one for the Internet (irc, im,
www, mail), another one for a work (dev, im). The first has rstack layout
with corresponding master width and windows order. The second has
bstack layout with an editor in master area and two terminals on the
bottom: one is tagged as dev (for output, debug...), another one is
tagged as im. Now you use just one key to change between these
desktops. Each one is comfortable for its purposes.
No need to rearrange windows and so on.
You don't need any changes in dwm.c to achieve this functionality. You
just have to define your keys your way. e.g. (not tested) :
#define WORKSPACEKEYS(KEY,TAGS, LAYOUT, FACT) \
{ MODKEY, KEY, view, {.ui = TAGS}
}, \
{ MODKEY, KEY, setlayout, {.v =
layouts[LAYOUT]} }, \
{ MODKEY, KEY, setmfact, {.f = 1.FACT}
},
And later:
WORKSPACEKEYS( XK_q, 1 0 | 1
1 | 1 2, 0, 55)
WORKSPACEKEYS( XK_w, 1 2 | 1
3, 1, 70)
...
This way you could chose workspaces with q, w,...
You could also write a little function to set this parameters and call
arrange just once to avoid flickering, or use a variable to be able to
cycle through them or change the values per workspace. I just want to
show that you can add all this without any complication.
OTOH, I have tried some similar approachs in the past (patching dwm)
and at the end I always come back to the original dwm tagging. If it
is easy enough choosing any set of tags (with view or tag), change
layouts, etc. having artifacts to remember the different states will
just complicate things.
Look, one of the reasons why you want to keep status bar is that it's more
simple to interact with it via mouse. It uses only mouse. But there is no way
to manage windows using only mouse, because you need to hold some meta
key, you know. Such title bars bring a possibility to manage windows
w/o keyboard (;
--
Hoc est simplicissimum!
maxim.vuets.name
As I have told before I completely use dwm _only_ with the mouse. I
use the clicks in the window title (or the root window) to call
move/resize window functions. Again, have a look at my config.h in the
customisation section if you want an example.
Why does everybody think dwm is not configurable? ;)
hth,
--
- yiyus || JGL .
Re: [dwm] dwm: request to discuss
2008/8/27 Maxim Vuets [EMAIL PROTECTED] Next, tags. Really cool idea for sure. But let's be honest: how much of us use them as tags, not as workspaces? I think not much. That was the one and only feature that set dwm apart from all other WMs. Desktops? You can write a patch, and if enough people like it (or Anselm), then it will make into the main stream. Status bar? Yes, I think it would be nice if the status bar could be written as a plugin: whenever something changed, dwm communicates it as a message (text) on stdout. Any application reading stdout can then do whatever they want with it. That would be simple to implement and offload managing the status bar in dwm. -- Cheers, Filippo
Re: [dwm] dwm: request to discuss
Yes, I think it would be nice if the status bar could be written as a plugin: whenever something changed, dwm communicates it as a message (text) on stdout. You can write a patch, and if enough people like it (or Anselm), then it will make into the main stream
