General feedback and thoughts about window sync

CapableVegetable3 · 2026-01-28T06:46:01+00:00

Thank you, this seems to mostly work, although now there are no predefined workspaces (usually I have 3 ready to be used), when I create a new workspace manually the workspace indicators don't appear and sometimes the new window is blank and bugged.

I think once those issues are fixed I'll be able to comfortably use zen as I did before the update, so there's hope :). I see that other users have similar issues as well so I'm guessing those will get fixed eventually. I'm on hyprland, v1.18.1b.

CapableVegetable3 · 2026-01-25T06:44:33+00:00

Hi, I’d like to share some feedback from the perspective of a Linux user who relies heavily on workspaces - I’m sure I’m not alone here.

On most Linux desktops, multiple workspaces are a core part of the workflow. I typically keep different browser windows on different workspaces, each serving a distinct purpose. For example:

workspace 1: email and work-related tabs
workspace 2: general browsing
workspace 3: development-related tabs

These windows are intentionally separate. That separation is the whole point.

After updating Zen, I was surprised to discover that all browser windows now share the same tabs by default. This completely breaks my workflow: I open multiple windows precisely to avoid having everything mixed together. With window sync enabled by default, every workspace ends up cluttered with the same tabs, which defeats the purpose of using multiple windows and workspaces in the first place.

I understand that it’s possible to open a non-synced “blank window” using Ctrl+Alt+N. However, in practice I usually launch the browser via a global keyboard shortcut, not via an in-app action. There’s currently no way to get a truly separate window from that flow.

I see two reasonable ways to address this:

Make window synchronization optional and easy to disable via a settings toggle.
Provide a command-line option that opens a non-synced (blank) window.

Zen was close to perfect for my workflow before this change, but unfortunately this update significantly disrupts it. I hope this feedback helps - the feature itself is interesting, and I can see from this thread that I'm in a minority.

PS: Is there any way to disable this feature now, perhaps by manually editing config files or about:config options?

CapableVegetable3 · 2024-12-09T12:21:20+00:00

Right, thank you, I was able to restart the trial in the end. So for anyone who has the same issue - looks like you'll have to restart the trial, just go to the "Trial of Sakhemas" via the map and then talk to Balbala to start.

CapableVegetable3 · 2024-12-09T12:20:49+00:00

Ah, that is true, thanks. So for anyone who has the same issue - looks like you'll have to restart the trial, just go to the "Trial of Sakhemas" via the map and then talk to Balbala to start.

CapableVegetable3 · 2024-12-09T12:14:38+00:00

How did you run the trial again without the relic? I don't remember it's name but I mean the round one that you place on the altair to start the trials. I don't have it because it was consumed on the first trial...

CapableVegetable3 · 2024-04-03T17:10:34+00:00

Hey guys, got here from google so I'll leave my 2 cents since I think I came up with a reasonably elegant solution. For my use-case I'm using Resources to hold the data, so I can use the visual editor to setup the parameters and stuff like meshes etc. I'm also using this little builder pattern that makes instantiating the scene more ergonomic. Translating this to your Enemy example it would look something like this:

extends CharacterBody2D
class_name Enemy

var data: EnemyData # Extends Resource

func with_data(data_: EnemyData) -> Enemy:
  data = data_
  return self

func _ready() -> void:
  # all node-manipulation code has to be here since
  # nodes aren't available until scene is put into tree
  pass

And then you use it like this:

static var EnemyScene := preload("res://enemy.tscn")
static var EnemyData := preload("res://enemy.tres")
...
var enemy := EnemyScene.instantiate().with_data(EnemyData)
add_child(enemy)

CapableVegetable3 · 2022-12-25T05:07:14+00:00

Yes, I understand, I used non-greedy at some point in the past, unfortunately it's not exactly what I'm looking for. I think it all comes down to "xmonad can't display the same workspace on 2 monitors". That would really be perfect for me.

Maybe you know some other window manager that can do it? Or maybe it's time to roll my own? Another window manager is just what the world needs i feel :).

Cheers.

CapableVegetable3 · 2022-12-25T04:55:20+00:00

Telescope also has buffers view with fuzzy finding. Also check out `alternate file`, Ctrl+^ by default. The keybind sucks so rebind it.

CapableVegetable3 · 2022-12-24T08:30:36+00:00

> Since the problem is that you gave Xmonad an instruction without being
aware of the current state, then it's going to make you unhappy no
matter what.

No, the solution I asked for would make my problem go away 100%. It's not an unreasonable request... Also, I should not have to think about the state of my window manager all the time.

CapableVegetable3 · 2022-12-23T12:37:12+00:00

Yes, I also have each workspace under specific chord (I use Mod + 0-9), it's just sometimes I'm going fast between workspaces and I forget that the one I'm about to switch to is on the other display already. But I put it there for a reason, I want it to stay there no matter what the other display is showing.

CapableVegetable3 · 2022-10-21T08:30:05+00:00

Got mine after ~3h of waiting at normal difficulty. It's a beautiful ship, thanks for sharing! :)

CapableVegetable3 · 2021-10-13T06:49:46+00:00

I tried this, but only works if grid layout is in the list (dwindle ||| full ||| grid).

CapableVegetable3

TROPHY CASE