Re: [dwm] dwm: request to discuss

2008/8/28 Maxim Vuets <maxim.vuets_AT_gmail.com>:
> 2008/8/28, Anselm R Garbe <garbeam_AT_gmail.com>:
>> 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
Received on Fri Aug 29 2008 - 14:40:06 UTC