Support for argument "--disable-server" to identify Thunar within unique scopes within children windows of the main process
This is a feature request
- Precursor
Thunar can identify itself with the options gtk3 provides
thunar --help-gtk
Usage:
thunar [OPTION…]
GTK+ Options
--class=CLASS Program class as used by the window manager
--name=NAME Program name as used by the window manager
--display=DISPLAY X display to use
--gtk-module=MODULES Load additional GTK+ modules
--g-fatal-warnings Make all warnings fatal
Window Managers like e.g i3, sway and many more can leverage that feature to make a window rule, to say, this window foo goes at this workspace.
As a user, it's quite straightforward to use the built-in "Thunar" identification.
However, if a user runs one Thunar instance, and then wants to run windows that are identifiable other than the Window title, or the already existing application identifier, there's a bit of an problem.
"Thunar" would be taken, and if the want is to say open a Thunar window for my disk at '/mnt/pictures', we would require to rely on the window title. And if the Regex to match the Thunar window is not precise enough (which can easily happen), or gets reapplied in context switches, then that's a bit of a hassle.
You can run Thunar from flatpak, so you get a second unique 'instance'. However, this does not solve the issue in a scalable way. You would need tons of these virtualized mini linux's... Not good.
Let's run through the actual use-case
- User starts thunar with it's default identifier "Thunar" at ~/
- User navigates to a different folder in e.g
alacritty, let's call it '/mnt/pictures' - User runs thunar --name thunar-pictures '/mnt/pictures'
- --name is automatically discarded for the sub-window
- Rule cannot be applied to the name identifier === Here would be great if we could have those children of the Thunar main process be allowed to have a unique identifier.
Why?
- Easier to make rules for it
- Less memory footprint
- Probably more reasons
What would need to be happen? Both --class and --name should work so we support both x11 and wayland.