Re: [dwm] dwm: request to discuss

2008/8/28, Anselm R Garbe <garbeam_AT_gmail.com>:

>> 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 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.

>> 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.
...
>> I want to use some layout scheme to one set of windows and
>> another layout to another set. dwm cannot do it.
...
> 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.?
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.

>> 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 ;)

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