[Original comment by TonyC]

Here are some ideas how this could be implemented (all open to discussion of course):

1. The bar already has the position directive. It should accept left and right as values, displaying i3bar vertically across the respective part of the screen.
2. When in a vertical position, tray icons should flow vertically from one end (my instinct is bottom to top)
3. Flush against the tray icons, the status text should read from top to bottom, using a horizontally aligned separator.
4. On the opposite end as the tray icons, the workspace buttons should ordered from top to bottom (my instinct is these should be placed at the top).

There is a tricky issue here that may require some thought. ''How do we support named workspaces?''

My suggestion is that workspace names should be read from top to bottom.

Technically, it seems like this would require a lot of changes to the code, so I would wait to start working on it until it gets official approval.

[Original comment by pie3mn@…]

According to the documentation ( http://i3wm.org/docs/wsbar.html#_dock_mode ), this would require changes to i3 itself to merely open up the possibility of vertical external workspace bars.

It was not my intention to imply that i3bar should ship with a vertical implementation.

[Original comment by TonyC]

Ok, I will file my issue later then.

I can confirm that xfce4-panel does not display correctly in vertical mode. i3 will not display a dock client in any other position besides the top or bottom of the output.

Unfortunately, the assumption that dock clients can only appear on the top and bottom of the screen is made at nearly every opportunity. Supporting vertical dock clients is going to take substantial changes to the code.

The only way I can see this feature being justified is if i3bar may one day have a vertical position option. Otherwise, the use case is too narrow for the amount of work to ever realistically be a priority. It's fair to say most people who use i3 also use i3bar, and only a fraction of those who don't would place a high value on a vertical dock client.

However, if i3bar may one day be vertical (I've already revealed that I think this is a good idea), then the changes would be justified.

If that is not a possibility, I will recommend this be closed as wontfix.

(I changed your title, using our terminology to clarify what is required)

[Original comment by pie3mn@…]

Well then, I added a placeholder vertical i3bar concept.

For this to make any kind of sense imho, you'd have to switch from mostly plaintext to some form of visual widgetry, parsed from the statusline or the like. Reading text from top to bottom really doesn't work that well.

I separated the bar into three "panels", workpan/traypan/syspan (TM)

Bunching everything together instead of spreading it out on a standard horizontal bar should reduce saccades and the distances between the panels wouldn't change depending on the screen size/resolution.

To reduce re-positioning of the panels when you open/close applications that create a tray icon, you could pass a "traypan_reserve" variable through the config, how many tray icons the traypan would reserve.

In the attachment that would be 3.- The notion here is that I think people know how big their tray usually is.

At the top of the workpan I added a clock (If there's doubt what this actually should represent). I guess you could easily move this to the syspan.

[Original comment by pie3mn@…]

I guess it would be better for workspaces to flow from bottom to top, as you stated first.

Also, I'm unaware of how flexible the tray implementation is, but I guess one could replace all kinds of "widgets" by plain trays? - i.e. using trays as mere "canvases"/pixelbuffers to visualize things like clocks etc. (tho I have my doubts that would actually work out alright)

One could also just throw out the idea of any kind of widgetry altogether, but then you'd probably wouldn't even be able to fit a clock in there and that doesn't sound much like a functional external workspace bar.

As you have already discussed, making i3bar support a vertical position (left/right) is a lot of work, with a lot of corner cases and unsatisfactory compromises/defaults. Overall, I think it’s not worth it.

As for i3 itself supporting the left/right dock position: I think conky does support these positions, or perhaps other applications. I think the original request was about such an application, but neglects to mention which one precisely it is. Could you clarify please?

Patches that make i3 support vertical dock clients will most likely be accepted.

[Original comment by pie3mn@…]

After rethinking the whole thing, I think there's a case to be made for a vertical i3bar that keeps the current paradigm of being mostly text. The bar just has to be wide enough for something like 5 readable monospace characters and I think you can do just enough with it. (Then special-UTF8-characters in your statusbar like crazy to save space)

In any case, I have no real insight into the internals of i3, doing a recursive grep for "_NET_WM_WINDOW_TYPE_DOCK" leads me greping "dock" which returns a reasonable amount of sources, but ofc. this doesn't necessarily mean anything how much of a workload it actually would be.

TonyC seems confident it's quite the work and I can easily see that to be the case.

The general problem seems to be that in the NetWM standard, a program can set the "_NET_WM_WINDOW_TYPE_DOCK"-hint (which seems to be simply a bool?) and then, somewhere else I presume, how much space is reserved for something like a bar ( is that http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idp6337880 it? ).

The i3bar docs: ( http://i3wm.org/docs/wsbar.html#_dock_mode ) implies that the NetWM specs actually specifies reserving space on the left and/or right edge for something like the bar but that it isn't currently implemented.

I'd love for someone who is familiar with the i3 code to make a quick look and give a rough estimate how much work such an implementation would really be.

I still don’t like that concept. It restricts you to far too short texts, not even an IPv4 address will be visible properly in such a bar.

Also, I am familiar with the source, and I think it’s not worth the effort.

(As for the dock question: _NET_WM_STRUT_PARTIAL is what reserves the space at the edge of the screen.)

[Original comment by TonyC]

I think this issue is pretty clear now. This feature will add support generally for vertical dock clients such as xfce4-panel.

I think discussion of whether to implement a vertical i3bar should be moved to a separate issue.

[Original comment by hhh@…]

Hi, I would really appreciate this feature. I wanted to have a vertical graphical conky panel.

Thank you for developing i3!

[Original comment by rladams@…]

I too would really appreciate this feature. I use Gkrellm, and it only provides a vertical docked information panel.

Oh no -- it should be me much simpler, and would be terribly useful. Don't bother with docking --- in fact, I don't use any dock thingies in the i3bar because that is, in imho, silly on a large screen. Just write the text from top to bottom or bottom to top --- if you can't read sideways, you're not using i3.

Everyone is starting from interactive notions pioneered in the 80s for 640x480 single black & white screens made for folks who had never seen a gui at all before. There's no reason that a project like i3 should cater to those sensibilities. Just give me the json text bar I have now, just rotated.

If I want docked thingies, I put them in a seperate graphical box, like stalonetray -- and in fact, it would be better to separate the informational text bar from interactive thingies. A menu and an info bar are different kinds of thingies, and sticking them together lead to all kinds of code complexities, interaction complexities and limitations of use. Text thingies can be quite small; interactive thingies need to be big, for example.

And I'd love the tabs also to be on the left or right --- exactly like now, just rotated.

Well, such a big feature would be built for a large group of people and I don't think for the "general public", reading sideways is a a route we should go down.

Why not? It's just a question of tradition, and the large group of people that i3 appeals to should have no problem adapting.

But once this "tradition" is set, it is set in stone and can't be changed easily. And I'm not convinced a 90 degrees rotated bar is really beneficial (also, I'm not sure XCB offers an easy way to rotate an entire pixmap like that).

I would like the ability to use gkrellm as well. This is the one thing keeping me from switching to i3 for my primary WM. Until then I have to relegate it to throwaway VMs for testing only.

I've seen a lot of people using other docks than i3bar with i3 so I think supporting this is worth having even without i3bar having it.

I think I will have a look at this in a while. Tony stated that the assumption of horizontal docks is made in a lot of places. I'll have to check whether the effort is manageable.

Now that _NET_WM_STATE_STICKY is supported, having a vertical dock is a matter of having a "right" gap on all workspaces, and have the dock being a sticky floating window ?

Floating windows don't take up space, so that wouldn't work. Besides, we want an implementation to be clean and not a hack.

By the way, this really is an extremely complex topic. I looked into it at some point and understand now what Tony originally said. I think supporting this is going to be a major change.

+1 for this feature, with today's screens being mostly 16:9 wide, it makes whole lota sense to have the ability to dock things on the sides.

Let's please refrain from +1 comments. If you want to show support, use the Github +1 emojis. Comments should be limited to things that add value to the discussion.

After playing around @vesim987's PR for 2 weeks, I would like to bring up the discussion again.

i3 currently resize/stack dock clients and I think this intended behavior make the feature more difficult to design. I think the easiest way to do this is simply don't resize/stack dock clients and placing them as them requested, but it will be a breaking change. Otherwise, it needs to decide what is the correct order to fill/place the docks (for example, Unity DE's top bar have higher priority than its left dock).

Here are some ideas to implement this while keeping resize/stack dock clients:

• Providing a user configurable way to decide which orientation always take higher priority.
• Simply use the order of the map requests but its not predictable according to Predictable bar ordering (when eg. 2 bars on bottom) #2797.
• Calculate a compact layout for docks from their strut hints (only stack a client when it is not possible to fit the rest of reserved space).

@zzzdeb Please use the GitHub reactions to voice support. "+1" comments trigger an email to everyonee who's watching this.

I would love to have something like WindowMaker dockapps in a sidepanel in i3.
Edit: Is it possible to give i3 an X offset (or margin) so it leaves a couple of 100 pixels on one side where sticky floating windows can go?

I have made the necessary changes to i3 core (not i3bar) (in branch 'vertical_docks' of my fork) and added right and left dock containers. You can't have vertical i3bar yet (unless someone changes that, because I have no interest in it) but you can use other vertical panels. I tested xfce4-panel, lxpanel, lxqt-panel, ukui-panel, and tint2. Besides some minor problems like not auto hiding and some of them not showing up on a second output, they work well.

I've have never contributed to a project and am a GitHub noob so please tell me if there is anything else I should do before even thinking about doing a pull request. I have read CONTRIBUTING.md but I can't do the testsuite because when I run testcases/complete-run.pl.in it complains and Google doesn't show any results. Also I'm not at all familiar with perl:

Can't locate i3test/Util.pm in @inc (you may need to install the i3test::Util module) (@inc contains: @abs_top_builddir@ @abs_top_builddir@/testcases/lib @abs_top_srcdir@/testcases/lib @abs_top_builddir@/AnyEvent-I3/blib/lib /usr/lib/perl5/5.34/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/5.34/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/5.34/core_perl /usr/share/perl5/core_perl) at ./complete-run.pl.in line 22.
BEGIN failed--compilation aborted at ./complete-run.pl.in line 22.

@arash-rohani Have you seen the testsuite docs already?

The commit seems fairly small. It's been some six years since I looked into this, but I remember this being much trickier than it looked on the surface. There are some obvious things that I wonder if you tested them, such as having multiple dock clients, even ones in different positions (e.g. left + top), etc.

@arash-rohani Have you seen the testsuite docs already?

The commit seems fairly small. It's been some six years since I looked into this, but I remember this being much trickier than it looked on the surface. There are some obvious things that I wonder if you tested them, such as having multiple dock clients, even ones in different positions (e.g. left + top), etc.

I have read the testsuite docs but I can't go past 3.2.1. Script: complete-run part because of the error. The previous steps went without any problems.

The multiple panels together is the first thing I've tested. Here is a picture running all of them at once:

I'm on Arch btw ( not sound like a meme :D ) so maybe there are more steps I have to take for testsuites to work.

I found out what the problem with the testsuites. I was looking in the wrong directory. In Example invocation of complete-run.pl in the doc it says cd testcases before running ./complete-run.pl but mine was directly in the build directory not testcases directory. Anyway I ran the test (it fails) and this is the log file: complete-run.log.

Some of the failures are fairly obvious because like dock client is as wide as the screen fails because well I changed the code to have variable width and height. But some of the failures I don't have a clue about like one dock client found failures. I don't know anything about perl so I don't know how to progress from here.