Predictable bar ordering (when eg. 2 bars on bottom)

[AloisMahdal]

I can have multiple bars, each with own purpose and different settings.

However, if I have 2 bars, say, A and B both in dock mode in bottom, the relative position of one to another is not deterministic: sometimes A will end up above B, sometimes otherwise. Even enabling and disabling one of them using i3-msg does not lead to reliable positioning (ie. it's not that the last enabled will be the "innermost" or "outermost".

This is problematic in my scenario where A is a "traditional" i3bar with workspace buttons, whereas B is just a custom status bar for media info (eg. current song). For mouse control, I always want the workspace buttons be in the lower-left corner, ie. need A to always be nearest to the screen border. B, on the other hand, does not need to run at all.

Here is how I want my screen to look like:

Currently (4.13-113-gd3901fe), I have no way of guarranteeing that. Closest I can get is to disable both and enable B, then A, but even that is not reliable (adding sleep helps).

It would be nice if i3 could at least make the positioning behave deterministically (eg. based on order in config or on id atttribute or order in which bars are enabled) or even make this explicitly configurable.

[Airblader]

the relative position of one to another is not deterministic

Actually, it should be. It depends on the order in which the applications request to map their window. The problem here is that while i3bar is part of the i3 suite, it's not directly / fully a part of the window manager. The actual i3bar window is still a separate, standalone client that i3 doesn't treat in any special way.

based on order in config or on id atttribute or order in which bars are enabled … or even make this explicitly configurable.

That's not possible because we don't want to make i3 aware of i3bar in that way.

I cannot think of a good way to do this other than you starting i3bar in sequence yourself, waiting for one to be mapped before starting the next one. I'm not really keen on adding the necessary complexity to do this in i3 itself because quite honestly I think this is an extremely rare usecase.

[AloisMahdal]

The actual i3bar window is still a separate, standalone client that i3 doesn't treat in any special way.

Isn't the fact that it does not have title and border, it does not stack/tab/etc. and it can only appear at edge already special? It might be OT here; I'm asking just out of curiosity, since I've heard the argument few times and I still seem to see some (probably ghost) differences.

I cannot think of a good way to do this other than you starting i3bar in sequence yourself, waiting for one to be mapped before starting the next one.

Well I have no idea how to do that. OTOH, for this particular case (clementine status), I can make do with my current n00b solution with sleep calls; adding few seconds to something I do few times a week won't hurt my productivity. (Maybe it will hurt pride of the desktop hacker inside me, but that needs to be hurt sometimes).

I think this is an extremely rare usecase

Well it's my first take on this problem, so maybe I have extremely rare way of using desktop ... which is what attracted me to minimalistic/tiled window managers (and eventually i3) in the first place. ;-)

At any rate, I can understand why you are being careful with the design, and I do appreciate that. I'm OK with closing this.

[jolange]

Isn't the fact that it does not have title and border, it does not stack/tab/etc. and it can only appear at edge already special?

It's special in the sense that it's a dock type window (_NET_WM_WINDOW_TYPE_DOCK).

[AloisMahdal]

It's special in the sense that it's a dock type window (_NET_WM_WINDOW_TYPE_DOCK).

Thanks for shining light on this. Looking at freedesktop spec, it does not say much about these:

_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows.

Anyway, if this RFE was rephrased as more general "add a way to control dock windows order", would it make more sense?

[Airblader]

If you can come up with a good way as to how this "way" would look like, sure. I can't think of a good way off the top of my head.

One thing we could do is make sure the directional move command works for up and down for dock windows. It would at least give you an easy tool to reorder dock windows.

Well I have no idea how to do that.

The X API allows you to listen for MapNotify events. Or you can use the IPC offered by i3 to wait for these events. As you pointed out a sleep is hacky, this would be the correct way to go (but requires scripting).

[orestisfl]

#4018