Re: [wmii] snap: 20060307

>
>
> > > /tags shows all unique tags which have been applied to any
> > > all clients.
>
>
> I'm glad to see that there is a place this information can be accessed.
> Although something similar to "pager" might be nice... only because I'm
> having difficulty knowing which workspaces are currently in use and which
> are empty (nice to know if you have that one application that wants the full
> screen and doesn't play well with others...). Perhaps I'll script something
> in the bar....
You are thinking wrong about things, there are no workspaces anymore,
except the current workspace, which happens to display all the windows
that contain a certain tag(s) (I'm still not convinced it is worth
allowing multiple current tags, from a theoretical POV it is not
necessary, and adds lots of complexity)

Still, there should be a list of tags currently in use in the status
bar, which allows
you to click on any of them and make that the current tag, that would
make visible (only!) windows with that tag. You can think of this as a
form of "virtual" ws, but it not really a ws.

> Two things annoy me about the new setup (which might be my unfamiliarity, or
> as-yet-unimplemented features).
>
> 1) Next "workspace" and Previous "Workspace": It was nice being able to
> scan through several pages of windows looking for updates (for example -
> work email in one ws, home email/chat in a second, etc.). Is this going to
> be possible? (Also, the left/right click on the bottom bar really helped
> scroll through them).
Yes, this is a troublesome spot for the tag-based window
classification as I already pointed out when I proposed the system.
IMHO cycling through workspaces was always a very inefficient way to
do things, I was used to it, but it was clearly a bad way to do
things. Tags still can be sorted alphabetically or something and one
could cycle through them, but IMHO that should be discouraged and
bindings to set the current tag to a specific value should be used
instead.

> 2) Delete a workspace as soon as it's empty: I very much understand the
> reasoning and thoughts here. However, it's become a bit annoying with some
> applications. For example when you open a document in Inkscape, it closes
> the current window and opens the graphic in a new window. So I'll go
> through the problem of opening Inkscape, moving it to a ws, opening an
> image.... then getting shoved back to another ws where I'll have to go back
> and retag it with the correct tag... Also, sometimes I'll have to run a
> slow loading application from an XTerm (rather than the wmibar). I used to
> background it and close the Term while it loads. Now I have to wait for it
> to show before closing the Term.
It is not surprising that many of this things will be problematic, but
I think that one of the assumptions for tag-based window
classification is that tags are pre-set based on the window name/id;
but I don't even know if a sane setup is workable based on that, and I
fear it would require extensive customization for the set of apps each
user works with.

A possibility(why is it not that way?) is to allow setting the current
tag to tags that are not currently in use, and retaining the current
tag even if there are no windows with that tag anymore, I think this
would fix most of the issues you mention and nothing would be lost,
because really, unlike with cols, there is no sane behaviour in case
all windows with the current tag are gone, jumping to
who-knows-what-other-tag is a _BAD_ idea.

All in all, I fear that garbeam, unsurprisingly, has succumbed once
more to his extreme chronic CADT despite my warnings that the tagging
system was just a crazy idea that might not work at all, and that
stabilizing wmii-3 was much more important.

Now a stable consistent wmii-3 is as far away as ever, and the idea of
tag based window management probably will end up scraped without first
going through proper research and design. *sigh*

And I ask once more: how many times do we have to go through this
totally senseless and idiotic process? How many ideas that might be
good or bad
have to be wasted because of a rushed and not well-thought implementation
on top of a base that has never worked properly?

uriel
Received on Wed Mar 08 2006 - 01:58:21 UTC