more granular show-titles setting

With show-titles = false, it's hard to visually distinguish a focused window.

Sway partially mitigates this by having a different border color for focused windows. I have a naive implementation for this, but it seems pretty ugly even with not much code and it's not the nicest thing anyway, so it wasn't something I wanted to pursue.

Another issue is it equally hides titles for both normal and floating windows.
Sway has default_border and default_floating_border settings to mitigate this.

I wouldn't necessarily want to emulate Sway in this regard, so I was considering alternatives.

A potential solution could be making show-titles have multiple options:

always - always shows titles, matching behavior of current true
multiple - only shows titles if there's more than 1 window on the output
floating-and-multiple - shows titles on floating windows and/or when there's more than 1 window on the output
floating - shows titles only on floating windows
never - never shows titles, matching behavior of current false

However, the stated goal of Jay is:

"Jay also aims to be forward and backward compatible for existing setups, allowing you to upgrade or downgrade the compositor without having to adjust your configuration."

I consider that very valuable, so I'm not sure how to go about this.
Adding another option (implementing these options if show-titles = true, while keeping show-titles untouched seems a bit messy.

No strong opinions, would be happy to hear thoughts.

Everything else aside, it would be perfectly possible for the show-titles option to accept either a string or a boolean. I think there already is at least one option that behaves like this.

Everything else aside, it would be perfectly possible for the show-titles option to accept either a string or a boolean. I think there already is at least one option that behaves like this.

Nice, I forgot about that!

How about something like this?

diff --git a/toml-spec/spec/spec.yaml b/toml-spec/spec/spec.yaml
index fa6c122c..cbab11c1 100644
--- a/toml-spec/spec/spec.yaml
+++ b/toml-spec/spec/spec.yaml
@@ -2882,10 +2882,10 @@ Config:
 
         The default is `true`.
     show-titles:
-      kind: boolean
+      ref: ShowTitles
       required: false
       description: |
-        Configures whether title bars on windows are shown.
+        Configures when title bars on windows are shown.
         
         The default is `true`.
     focus-history:
@@ -4331,3 +4331,29 @@ BarPosition:
       description: The bar is at the top of the output.
     - value: bottom
       description: The bar is at the bottom of the output.
+
+
+ShowTitles:
+  kind: variable
+  description: |
+    Configures when title bars on windows are shown.
+    
+    - Example:
+    
+      ```toml
+      show-titles = "multiple"
+      ```
+  variants:
+    - kind: boolean
+      description: |
+        If `true`, titles are always shown. If `false`, titles are never shown.
+    - kind: string
+      description: |
+        Configures when title bars on windows are shown.
+      values:
+        - value: multiple
+          description: Titles are only shown if there is more than one window on the output.
+        - value: floating
+          description: Titles are only shown for floating windows.
+        - value: floating-or-multiple
+          description: Titles are only shown for floating windows or if there is more than one window on the output.

I would like to understand why people are using show-titles = false in the first place.

I would like to understand why people are using show-titles = false in the first place.

Sure. In my case it's pretty simple and stems from using bar-position bottom like I'm used to in i3 and Sway.

If you have something on an output with controls on top, if there's nothing above it's very hard to missclick anything. If titles are enabled then you're aiming between controls and the title (or bar with bar-position top).
An obvious example are browsers like Chrome and Firefox with tabs on top. Both have a clickable area in tabs all the way to the top, which in this case ends up being on the very top of output, making it hard to miss.

Obviously, with a very keyboard focused workflow, this isn't a very big deal, but it makes a difference.

Other than that, it's also a matter of visual taste. I prefer no title bar when there's nothing else on the output because it doesn't really serve anything.

Regarding the config proposal, since then I've done a naive implementation that I want to refine a little bit before getting it to you (there are some caveats with multiple and counting both tiled and floating windows).
However, I've been considering a simpler approach of just having true, smart, false to avoid having config overload. smart essentially being floating-or-multiple.

If you have something on an output with controls on top, if there's nothing above it's very hard to missclick anything.

How about moving titles to the bottom as well?

Other than that, it's also a matter of visual taste. I prefer no title bar when there's nothing else on the output because it doesn't really serve anything.

They do serve the purpose of telling you which window has the focus. How about an option that leaves the bars as is but doesn't render the window titles?

I'm also thinking that this could be a window rule.

How about moving titles to the bottom as well?

Wouldn't mind that being an option, but would definitely prefer having an option to disable them completely.

Other than that, it's also a matter of visual taste. I prefer no title bar when there's nothing else on the output because it doesn't really serve anything.

They do serve the purpose of telling you which window has the focus.

Not if there's only 1 window on the workspace. Yes, you can theoretically have only 1 window on the workspace but not focused, but that's not something I encounter or consider a problem.

How about an option that leaves the bars as is but doesn't render the window titles?

I wouldn't mind that option being there, but it's not something I'd use because of wasted space on top/bottom and just purely visual preference.

I'm also thinking that this could be a window rule.

Why not? 🙂

I wouldn't mind that option being there, but it's not something I'd use because of wasted space on top/bottom and just purely visual preference.

AIUI you don't have a problem with sway drawing a border around windows.

Why not? 🙂

I imagine it would be a window rule that applies to containers and floats combined with two new actions that allow you to show/hide the titles rendered by that particular window.

I wouldn't mind that option being there, but it's not something I'd use because of wasted space on top/bottom and just purely visual preference.

AIUI you don't have a problem with sway drawing a border around windows.

Hm, not sure if it's a default or not, but my Sway setup has pretty much the same looking borders between windows as the default Jay setup. Except that Sway treats them as borders with windows having a border each (with color if focused), while Jay has separators between windows.

Seems like Sway default for default_border is normal 2 which includes a 2px border and a title bar.
I use:

default_border pixel 2
default_floating_border normal 4

This removes the title bar, keeps the border, while having a title bar and 4px border for floating windows.
This mirrors the behavior on i3.

Why not? 🙂

I imagine it would be a window rule that applies to containers and floats combined with two new actions that allow you to show/hide the titles rendered by that particular window.

That could work. Can kinda emulate the difference between normal and pixel in i3/Sway.

I imagine it would be a window rule that applies to containers and floats combined with two new actions that allow you to show/hide the titles rendered by that particular window.

That could work. Can kinda emulate the difference between normal and pixel in i3/Sway.

Yeah, having read up a bit more, simple actions for show-title and hide-title would essentially cover almost all I wanted. Current ones are for the global setting only.

Basically, this:

show-titles = true

[[windows]]
name = "browser"
match.any = [{ app-id = "chromium" }, { app-id-regex = "^google-chrome" }]
action = [{ type = "move-to-workspace", name = "2" }, "hide-title"]

I would like to understand why people are using show-titles = false in the first place.

I usually disable titles because I almost always know what the window is or what it's a child of, leaving titles on just takes up more space for me. Jay is the only window manager that I have titles enabled (and even then, at 2px) because it uses separators rather than borders which can't be recoloured to show the currently focused window, and it's also to tell window position in a mono group or even if a container is a mono group without the title (this one could be resolved by adding a mono-title-height or similarly named option).

Ideally, I would be able to setup something like this with minimal additions to jay:

@mahkoh

@mahkoh

I imagine it would be a window rule that applies to containers and floats combined with two new actions that allow you to show/hide the titles rendered by that particular window.

To me this feels like the right move, being able to add client/window rules and apply specific theming. I would use it for my floating app launcher which currently has ugly title and borders :)

This is implemented in #1128.

This has been implemented.

Navigation Menu

Repository navigation

more granular show-titles setting #678

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

more granular show-titles setting #678

Description

Activity

mahkoh commented on Dec 2, 2025

kotarac commented on Dec 2, 2025

mahkoh commented on Dec 4, 2025

kotarac commented on Dec 4, 2025

mahkoh commented on Dec 4, 2025

kotarac commented on Dec 4, 2025

mahkoh commented on Dec 4, 2025

kotarac commented on Dec 4, 2025

kotarac commented on Dec 4, 2025

Stoppedpuma commented on Dec 7, 2025

Alphare commented on Aug 25, 2026

mahkoh commented on Aug 25, 2026

mahkoh commented on Sep 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions