search

i3 / i3

A tiling window manager for X11
https://i3wm.org/
BSD 3-Clause "New" or "Revised" License
9.43k stars 777 forks source link

Concise split container titling combining window (class_instance) types for user friendly display #4762

Open jtaala opened 2 years ago

jtaala commented 2 years ago

I'm submitting a…

[ ] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)
[X] Enhancement

Current Behavior

Current split con titles, while technically a correct representation of child windows, are not concise or or easy for users to mentally process child window information.

Please note I'm referring to split container title formatting and not window title formatting. The former is not configurable like window titles are.

Expected Behavior

Display split con tree information in a more concise and user-friendly format (or an option to do so).

I've implemented what I believe to be an appropriate split con title format in my fork's rewrite of the con_get_tree_representation function - see branch concise-con_get_tree_representation-rewrite).

You can see the difference compared to the current i3 split container title formatting in the two images below (the first is with my fork's changes): i3-concise-con-tree-representation-crop

compare this to the current split con titles: i3-current-con-tree-representation-crop

Note I'm just putting this up to see what others think or if there is interest in providing this type of enhancement in base i3wm. If there is, I'd be happy to have the current split con title formatting as default and provide the ability to turn on concise con split titling via an option etc.

If not, I'm happy to continue supporting this enhancement via my fork.

Environment

Output of i3 --moreversion 2>&-:

Binary i3 version:  4.20.1-3-g7c015564 © 2009 Michael Stapelberg and contributors
Running i3 version: 4.20.1-3-g7c015564 (pid 1529893)
Loaded i3 config:
  /home/jay/.i3/config (main) (last modified: Fri 31 Dec 2021 15:31:16, 13256 seconds ago)

The i3 binary you just called: /usr/local/bin/i3
The i3 binary you are running: i3-with-al/bin/i3
i3bot commented 2 years ago

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

i3bot commented 2 years ago

I don’t see a version number. Could you please copy & paste the output of i3 --version into this issue?

Airblader commented 2 years ago

The former is not configurable like window titles are.

Yes, it is, but naturally such containers must be targeted using the con_id match criterion. A script could rewrite the titles externally without having to modify i3.

jtaala commented 2 years ago

The former is not configurable like window titles are.

Yes, it is, but naturally such containers must be targeted using the con_id match criterion. A script could rewrite the titles externally without having to modify i3.

Thanks @Airblader , yes I've played the script game :-(. However, in this case I don't believe a script could be used to mimic the end result in the screenshot, e.g. the nice superscript indicating the number of instances of window types etc. (I'm happy to be proven wrong though :-).

Simply because the current implementation does not show split con titles in pango format (for example). See one-liner change needed to do so in x.c here.

jtaala commented 2 years ago

@Airblader, but yes, I understand what you're saying (and I don't disagree with the principle). Perhaps I should have just put the one-liner change change for the enhancement so a script could set the container titles and would/could display in pango format :-).

Airblader commented 2 years ago

Simply because the current implementation does not show split con titles in pango format

That's only when no title_format is set, which your fork needs since you modify i3 internally. A script that sets the title_format would be able to use pango unless I'm missing something?

jtaala commented 2 years ago

That's only when no title_format is set, which your fork needs since you modify i3 internally. A script that sets the title_format would be able to use pango unless I'm missing something?

Now I could be missing something here, but if you follow that function through, the con tree representation is always pango escaped since window is NULL for split cons (see this line). In my testing (yes, I did try previously the scripting approach... it didn't end well) the con_tree_representation was always pango escaped (i.e. didn't render pango).

Airblader commented 2 years ago

The line you linked to is just for the %title placeholder that you can use in title_format, though. Your script wouldn't be using that (since it's kind of useless there) and rather pull the titles of the children from the tree.

That said I don't have access to a machine to try it out right now, I'm just reading the code on mobile here.

jtaala commented 2 years ago

That said I don't have access to a machine to try it out right now, I'm just reading the code on mobile here.

Dang, that's hardcore dedication right there!

No, I did pull child (leaf) names from the tree - but regardless of this - trying to change the split con title via script (e.g. since split con is always win == NULL) resulted in escaped pango split con titles (e.g. I'm not interested in changing window titles just the split con titles).

Airblader commented 2 years ago

I'll try to verify this later on, but if custom title formats on split containers don't support pango, I would agree that that's something we should look into supporting.

That said, I don't think the superscript is absolutely necessary; you can get most of the effect you're looking for by doing something like app(3) as well.

jtaala commented 2 years ago

@Airblader P.S. full disclosure I just tested changing split con titles to some pango test string via script (isolating a con_id of a split con etc.) and that was a while back...

P.S.S. I've also been known to be mistaken and also messing things up (from time to time)...

jtaala commented 2 years ago

That said, I don't think the superscript is absolutely necessary; you can get most of the effect you're looking for by doing something like app(3) as well.

I know... and don't disagree... although they are pretty nice :smile: .

Note: I revert to that app[x3] if no pango font.

Airblader commented 2 years ago

Using pango markup for title_format of a split container works fine for me:

i3 "[con_id=94761264365728] title_format test<sup>123</sup>"

screenshot-2021-12-31_13-46-30

→

screenshot-2021-12-31_13-45-46

jtaala commented 2 years ago

Using pango markup for title_format of a split container works fine for me:

i3 "[con_id=94761264365728] title_format test<sup>123</sup>"

screenshot-2021-12-31_13-46-30

→

screenshot-2021-12-31_13-45-46

A thousand apologies @Airblader! I don't know why my recollection thought that... I even have a bindsym in my current config (that I've had for a while) which sets a split con using pango! (e.g. exec "i3-msg focus parent; i3-input -f \\"-*-*-*-*-*-*-24-*-*-*-*-*-*-*\\" -P \\"Name child container: \\" -F 'title_format \\"<span><b>%s</b>%title</span>\\"'; i3-msg focus child").

Again, apologies for my confusion there! :confused:

Airblader commented 2 years ago

Right, no worries. So in conclusion, the feature presented here is possible via an external script. Arguably it is much more effort than your fork, though I don't see that as a big issue.

As far as the request itself goes — I'd definitely not want to introduce any kind of further configuration here as it's impossible to make it both generically useful and low in complexity; that's exactly what title_format is for.

So the remaining question is whether "just making the change" is worthwhile. Since code and user impact are pretty small here, that's mostly a question of how useful is the change.

jtaala commented 2 years ago

Thanks @Airblader - and happy new years btw!

Yes, I agree with your thoughts there and it boiling down to how useful the change is. Also agree that configuration would prove difficult to keep it generic and low in complexity but useful (in terms of availability of formatting options/config).

As for "just making the change" and it's usefulness - I use parent containers often and have always found the current titling not user-friendly and not useful for any complex or semi-complex child layout. So this change has been a significant improvement and the type of format I feel should have been the default for split cons... however I'm biased here! (since I wrote it) and realise others may like the current representation of the tree in split cons...

Thoughts on it's usefulness? Could leave this issue up and see if anyone else jumps in with their impressions.

Airblader commented 2 years ago

Thoughts on it's usefulness? Could leave this issue up and see if anyone else jumps in with their impressions.

Yeah, I think best would be to wait and see a bit if other people have thoughts on this too.

and happy new years btw!

Same to you!