Re: [wmii] snap: 20060307

On Wed, Mar 08, 2006 at 01:58:19AM +0100, Uriel wrote:
> 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)

I agree on this for selecting a workspace. I think that select
'1 2' to construct a workspace is too much complexity we do not
really need. Instead it is sufficient to tag clients with more
than one tag that they appear in different workspaces.

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

Exactly that is what will be the case in the afternoon.

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

You cannot base on window name, because it changes randomly.
That is why I go for /def/tag which allows the user to use his
own mnemonic tags without relaying on client
name/class/instance stuff. Though a way to apply tags to
specific class/instance stuff will be cool as well.

But much more important is to allow class/instance based
hinting to define if a client should be floating/managed by
default. (I also considered tags to only apply to floating OR
managed clients, but this would break a sane transient handling,
and is not easy to understand and work with in a proper way).

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

Exactly, thus I stick with /def/tag.

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

As I told, a good way is to simply wait with destroying the
virt-ws until a new 'tag' is selected. Thus, the currently
selected tag is valid, even if no clients are attached anymore
(new clients will inherit this tag).

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

wmii-3 is quite stable already beside some glitches which have
been introduced through this tagging stuff. But it is better to
introduce the tagging stuff before wmii-3, that we do not need
to change the core once again after wmii-3. And yes, shame on my
head that this is CADT, but shame on your head that you didn't
got this idea earlier and proposed it earlier ;)

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

That is not true. In contrast to you, I always work with hg tip,
the last big changes has been 9P integration.

> have to be wasted because of a rushed and not well-thought implementation
> on top of a base that has never worked properly?

The base has worked fairly well since we got rid of libixp(old).

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361