Support Awesome-style tags

[Yamakaky]

Instead of i3-style workspaces, did you consider using awesome-style tags? I found them much more useful, and workspaces can be "emulated" using tags. It's why I stick to Awesome instead of workspace-based managers.

[cherti]

seconded, awesome-style tags are superior compared to one-workspace-only as the latter is just a special case of the former, but tagging is much more powerful when managing clients, as one can enable multiple tags at once, e.g. to see everything on the 'web'-tag + everything on the "code"-tag.

[SnirkImmington]

I don't use the tagging feature as much in Awesome so I was thinking of just having named workspaces. However, we could probably find a way to fit that in our layout tree somewhere. I had been putting off the Awesome side of layout because I assumed the way awesome lays out windows automatically would be a little trickier to implement on top of i3's manual style (but not impossible). I'm also not writing most of the layout code.
I do think it would be possible to do, however. I'll look into bringing some Awesome features in.

[Yamakaky]

That would be cool. The readme doesn't even have to change, since displaying one tag at a time is the same as using workspaces ^^
Use case: I have three fixed tags (firefox, terminal and thunderbird) which are always open, and 4-9 which are allocated for the rest. I often activate multiple tags, like firefox + terminal

[SnirkImmington]

Yeah, we have a "name" field in the workspace code right now for that purpose. Once we have a bar you could definitely see the names of the workspaces and (with rules) bind windows to them.

[cherti]

having tags would be really great! proper tagging is one of the crucial things I need and if way-cooler would provide that I might have found my WM for wayland once Wayland is adoptable enough (e.g. everything I need works^^). :D

I usually use tagging to have one tag for code, web, videos and so on and just enable that combination I currently need (e.g. code + web for programming + api-website/stackoverflow, code+videos for just pumping straight forward code etc.).
That allows for quick and extremely convenient compositing the set of windows I need at that very moment.

[Timidger]

Is there a resource I can look at that explains Awesome tags better? I used awesome once upon a time, but like @SnirkImmington I never utilized the tag feature. Is it just a way to view windows from multiple workspaces at once or it fancier than that?

[cherti]

I don't know about a particular resource, but I'll try to give some background.

tl;dr: yep, more or less viewing windows of multiple workspaces.

To make sure there are no misunderstandings, the long version below:

beforehand, the idea of workspaces/virtual desktops/you name it:
one has n workspaces. exactly one workspace is active, the screen is filled with all (not minimized, invisible, etc) clients on that workspace. Clients can be on multiple workspaces, e.g. my IDE can be on the workspace "coding" and on the workspace "coding with browser", whereas my browser can be on the workspace "coding with browser" as well as "browser only".
Each client may have multiple workspaces assigned* and is visible if one of its assigned workspaces is the active.

tagging takes this a step further:
clients can save serveral tags assigned* and I can, like with workspaces, have one tag active. In that case, it behaves exactly like workspaces. But tagging goes a step further, allowing for multiple tags to be active. so I can activate both tags "coding" and "browser" (and more if I decide to) at the same time and my screen is then populated by all (nonminimized...) clients that are associated with at least one of the active tags. So I can enable the tags "browser" and "coding" at the same time and I have the same effect like with the workspace "coding with browser", but with one workspace left and less hassle with placement rules, because there is just one tag the browser must be associated with.

I personally use it to group windows by purpose and then combine the tags in the way I need.
(e.g. coding + browser for api-reference + music-tag for the music player while coding). and each of those groups is easily deactivatable by deactivating the tag.

This is possible with workspaces as well, but the matrix of combinatorical workspaces you need would obviously blow up quite qickly.

Does that answer your question, @Timidger? Anything left you are wondering about?

*) if clients have tags/workspaces assigned or the other way around is of course a detail of the implementation

[Timidger]

Ok, I think I understand...So tags are a separate entity from workspaces? I.E: Clients still live on a single workspace but can be associated with several tags? How do you associate client with tags, or are they placed in a tag and for all intents and purposes could be considered a workspace except that they also have the special properties of the tag?

Being able to have multiple workspaces active is easy, but having a client associated with multiple workspaces/tags would require some redesign of how the tree is currently set up. Which is fine, it just would take more time as I figure out how to incorporate it while remaining flexible.

[cherti]

So tags are a separate entity from workspaces?

Tagging, as implemented in awesome, completely replaces the concept workspace.

If I always have only one tag active (like I did a long time, before actually leveraging the power of tagging), I have the workspace-concept back. Tagging is the more general concept here, so if you have tags, you don't need workspaces, as workspaces are so to say only a special case of tagging.

awesome allows both having multiple tags/workspaces active at the same time and having windows placed on multiple of them as well.

For me personally, having the possibility to activate multiple workspaces/tags at the same time would actually be sufficient as I use tagging to have purpose-oriented grouping of windows.
I don't really use the latter part of what awesome allows, so having the "multiple tags active"-feature combined with some rules to automatically sort every window on the tag it belongs on, I'd be perfectly happy.

[Timidger]

Ok then, I'd need feedback on others then to understand how much I should try to recreate Awesome's tagging system. Having the ability to view multiple tags/workspaces at the same time would be much more trivial to implement compared to having multiple views associated with multiple tags.

Anyone else have any thoughts?

[cherti]

@Timidger

Thinking about what you wrote:
what happens if you have three tags activated and a new window spawns, where will it be placed?
Either on all tags visible (that's how my awesome currently handles that) or you would need a different solution. Maybe this concept might be interesting (which is more or less an extension/extended version of awesome's default tag-model).
It's from one of the awesome-devs and it sounds at least interesting, although I personally don't use it. Maybe you want to draw some ideas from it, maybe not.^^

(Just flooding you with info as long as things can still be changed comparatively easy ;) What you do with it is then up to you :))

My main interest keeps to be having multiple tags activatiable at the same time, but just in case you want to go beyond that. :)

[Timidger]

Oh please keep flooding me with info, this is a long way off and something I'm going to thinking about for a while.

We could hypothetically have containers on multiple workspaces, but it might complicate some of the rules that assume a single parent. However, I plan to add a more complicated pathing system that will allow more features (includibg remembering which view in a container was the last used), which might enable this to happen.

If a new window is spawned it shouldnt clash with the current rules though. If the active container is a view, then it's added as a sibling, otherwise it'll be added as the child if the active container. So kind as a view can only be on one workspace/tag, you can choose which workspace/tag to move it to by simply moving it into that container or by opening it while selecting a container from that workspace/tag.

[Timidger]

@cherti, I took a look at that link, and I am intrigued by the complicated rules system in play there. The most I've done with rules has been very simple (e.g: Firefox, go in my web workspace, etc.), but I can both myself and others benefiting by having a rule system at that complexity.

However, a rules based system would probably have to wait until after the other tree features are added (most notably paths), since I'd want those to be concrete before embarking on something designing a system that would have to play well with what we have.

In the mean time, I'll take a look at other rule based systems in other WMs. When I have a more concentrated idea of what I'm thinking of I'll open a RFC style issue on here for others to weigh in on the decision. That probably won't happen for a couple months though.

[cherti]

speaking of rules: this scratches a little on the surface with what's possible with rules. especially callback is of course extremely powerful.

[SnirkImmington]

I remember using Tyrranical for a bit. It was definitely much better than awesome's rule handling. However, like tags, it does start to complicate the idea of the layout tree.

I'm starting to think we'll need something more complex than edgeweights in order to facilitate this. One of the advantages awesome's layout has is it's more automatic: their layout algorithms are described in terms of some number of windows and adding new ones changes where other windows are in the list. We chose to first go with i3 style layout because it's more versatile, and I had always said we could implement automatic layout on top of it.

However, adding in tagging (especially some of the advanced features) starts to overcomplicate the basic model. Determining where a window is laid out is no longer purely a tree method - we'd have to consider some views in other workspaces, views which follow some "rule" (i.e. selected tag), as well as grouping views into containers and recursively laying out children.

We need to consider:

1. What the user is focused on. No longer just "active container + children", it could also encompass containers on other tags. So a set of active containers at the very least.
2. The tree structure of the views to render - We need many aspects of the layout tree, and we need it to work as expected if you don't use the fancy features
3. Floating or maximized views
4. Laying out the views based on their tree structure - horizontal and vertical layout containers
5. Laying out the views based on where they come from - if you have two tags selected where do the views go?
6. Laying out the views based on user-defined presets and layout rules - to achieve awesome-style automatic tiling (I can open 3 terminals and they go where I want them to go), we need to provide easy hooks to "layout algorithms" and allow each tag or workspace to have a different one

The tree layout code is already very long and complicated, I'm going to take a look at how awesome does it in awful.rules and help @Timidger with the code more. As he said though, probably won't be finished for a while.

[Timidger]

@SnirkImmington

1. This will be covered in the pathing system
2. Right now it is very simple, but it can scale simply. If you want to render everything correctly from two different workspaces, you can just take children of root container node of the other workspace you want to add, and make it so that it is rendered as a child of the root container of the original workspace.
3. Yeah that needs to be considered.
4. Yep, that should keep happening even with tags, since the two workspace container trees can be considered disjoint (for now, still thinking about duplicating views across workspaces)
5. I'm still thinking about this, but my general idea is this: Right now, workspaces have a "root" container, which is always there and is the only container that can have no children. If you are on workspace 1 and add workspace 2 as well to be viewed, then you draw the root container of the second workspace as a child of the root container of the first workspace. This will allow you to change the way workspace 1 and workspace 2 containers are laid out in relation to each other as a whole (e.g: You want to have a tabbed view where you can switch back and forth easily? You can do that)
6. Yeah, I still need to think about that and will probably be done either just before or after the pathing (it's not blocked by that). I was thinking to just have a special container that would have that layout information, encoded with a lua script perhaps? When tiling that container, the normal rules would stop applying when entering that container and the Lua script would take over. This would let you mix and match. It would be cool if you could move in and out of it as you go down the children of the container, but that might be more difficult to accomplish, but doable.

[cherti]

@Timidger
you wanted to be flooded with ideas^^, so:
another thing in this regard: it might be useful to have the possibility to place windows on every tag/workspace/whatever it will be called in the end.
Usecases for this include:

• dialog-windows to be placed on every screen to not miss them (like "do you really want to perform x?", "do you really want to send email?",...) and stuff like that
• I use something like that to have one terminal that I can just quickly call that overlays everything else for things like quickly trying something out in a python-shell and things like that. This prove to be extremely useful as it significantly reduced the number of spammed terminals.

Therefore if the decision falls to not being able to have windows on multiple tags at the same time, it might still be worth considering the case of all tags.

[Yamakaky]

As an Awesome user, I never add multiples tags to a window. However, I'm always displaying multiple tags at the same time.

[Timidger]

@cherti That's an interesting use case I had not considered. For your second point though I can see a quake terminal being a suitable replacement.

@Yamakaky You highlight an important distinction about the features being discussed here (because there's really two): ability to have windows present on multiple workspaces, and having multiple workspaces active and visible to the user. The first would require some reference counted system, which could complicate things quite a bit, while the second one just requires us to rethink how displaying works (which will ultimately just affect active paths (once I'm done implementing that) and the layout code, because there won't be any actual transformations done to the tree itself, it's all visual).

[Yamakaky]

I think the only times a window has multiples tags (with my setup) is when I open an application while multiple tags are active.

[cherti]

@Timidger
The "display on all" might be implementable after all by a dynamic workspace or something? I think i3 uses something like that (scratchpad or so?), although you don't have the possiblilty to display it additionally to other workspaces.
But if you implement displaying of multiple workspaces, this might be a valid (and probably easy) way to actually implement that, even soley in the user-config, so no changes to the upstream-code necessary for that.

And as I already mentioned, I found myself using tags similar to @Yamakaky. So I wouldn't be too sad if you don't implement multiple tags per window as long as I can get my "display everywhere" running somehow. ;)

[Timidger]

Yeah, I think scratchpad is something like that (I don't use that feature of i3, but I'll look into what it is to be sure that it's a subset of the functionality described here).

Ok, if no one is particularly upset by the exclusion of a window having multiple tags associated with it I'll go ahead and shelve it for now.

I'll make a new issue to allow multiple workspaces to be viewable. With your workflows @Yamakaky and @cherti, do you prefer having a specific workspace/scratchpad like thing where windows can exist on all workspaces, or are you ok with having multiple workspaces active/viewable at once. You can achieve the same effect by mentally designating one workspace to behave like that (e.g the last one or something) and just keeping it active while you go about your work.

[SnirkImmington]

I haven't tried to get windows displaying on multiple monitors before. I'm not sure if that will be tricky to do with wlc. I can see it being very useful though.

I'm in favor of moving to make workspaces and layout more flexible, so that a "scratchpad" workspace could be implemented within our system.

@Timidger and I will be considering the broader impacts of taking ideas from different window managers and styles, but for now we have #105.

[Yamakaky]

Not sure what you mean @Timidger. Personally, I use the following actions:

• add/remove a tag from the current view
• select a tag to create a new view
• to switch with the last view. For example, I can switch between term and firefox+mail

[Timidger]

@Yamakaky

I realize I was confusing the feature set of i3 scratchpad and awesome's tags, my mistake.

[Timidger]

Since concenses has more or less been reached, please direct any more conversation about multiple workspaces being visible to #105. If there are any more comments about tag support, either fully or partially, with the current workspaces please open another issue.

We will consider adding bigger customization changes, like having tags as opposed to workspaces, in the future. Other parts of Way Cooler need more work before we can build such a flexible system.

[Timidger]

Thanks to discussion in this thread it should be possible to implement this feature along side the current tiling.

What this means is that if you have for example a browser pinned to both your "browser" tag and your "music" tag (eg if you use the Spotify web client or Pandora) then if you open both up instead of choosing which container to render it in it would render it twice.

I'd have to make sure it renders the client content properly, because it just duplicates what the client sends us and that can be different depending on the size of the container (which can differ per tag. But it's the best way to add the is feature with out artificially restricting it to awesome the style tiling only (which wouldn't have this restriction)