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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
