First of all, huge thanks to the devs that implemented the split view. Was a sorely missed feature to the otherwise great file manager!!!
Now, using split view much more often than not (read: almost always), hitting F3 every time Thunar is opened gets a bit annoying after a while.
So having an option/preference to always enable it would be great.
Meanwhile, if somebody needs it, as a partial workaround the following command can be used for panel launcher (or in the .desktop file):
# Bash:bash -c 'thunar & disown %1 && until wmctrl -a "Thunar"; do sleep 0.3s; done && xdotool key F3'# Or if regular shell is preferred: sh -c 'nohup thunar >/dev/null 2>&1 & until wmctrl -a "Thunar"; do sleep 0.3s; done && xdotool key F3'
wctrl and xdtool need to be installed, and it works only for the first window opened or if no other apps/windows have "Thunar" in their title.
If it doesn't work at all, sleep 0.3s is probably too short.
Humm actually non of the other file managers (Nautilus, Caja, Nemo, Dolphin, PCManFM) behaves like that. So for the sake of compartibility, lets rather make it a hidden setting. E.g. "misc-force-split-view".
I dont have time to work on it, though a MR would be welcome !
Humm actually non of the other file managers (Nautilus, Caja, Nemo, Dolphin, PCManFM) behaves like that.
Not sure what exactly do you mean, but if it's having a preference to toggle split-view by default, Nemo and Dolphin do have it (SpaceFM as well, though it simply remembers the layout instead of having an explicit option/toggle for it).
Regardless, as far as I'm concerned, hidden xfconf value is perfectly fine (heck, I'd be just as happy with only a compile time option). :))
I dont have time to work on it, though a MR would be welcome !
I did try the "quick & dirty" method of just calling thunar_window_action_toggle_split_view at the and of thunar_window_init (in thunar-window.c), but it's unfortunately not that simple.
It works in a sense that Thunar does start with two panes, but the left one is empty and dead (unresponsive to input)...
Anyhow, ignoring my almost non-existent C-foo I'll give it a (proper) shot, popping an MR if something reasonable comes out.
Humm actually non of the other file managers (Nautilus, Caja, Nemo, Dolphin, PCManFM) behaves like that.
Not sure what exactly do you mean, but if it's having a preference to toggle split-view by default, Nemo and Dolphin do have it (SpaceFM as well, though it simply remembers the layout instead of having an explicit option/toggle for it).
If you have a window open with split-view on e.g. SpaceFM. Than you press File-->New Window. Than the new window will not have split-view. (Same for all other file managers).
So I think thunar should behave the same by default.
I did try the "quick & dirty" method of just calling thunar_window_action_toggle_split_view at the and of thunar_window_init (in thunar-window.c), but it's unfortunately not that simple.
It works in a sense that Thunar does start with two panes, but the left one is empty and dead (unresponsive to input)...
Check thunar_application_open_window. There you just need to add thunar_window_notebook_toggle_split_view.
For the hidden xfconf value, check how it is done for other hidden xfconf values, e.g. misc-always-show-tabs.
If you have a window open with split-view on e.g. SpaceFM. Than you press File-->New Window. Than the new window will not have split-view.
Yes, unless the option to always start with split-view is enabled. Verified in Nemo and if memory serves me, should also be true for Dolphin.
SpaceFM is different in this regard since it has separate toggles for each available pane, and it simply always restores the last/current layout, whatever it is and regardless if opening a new window from current one or restarting.
So I think thunar should behave the same by default.
Agreed!
Though just to reiterate and make sure we're on the same page:
misc-always-enable-split-view TRUE:
First and all subsequent windows have split view
misc-always-enable-split-view FALSE:
All windows start with single pane, even if current one has split view toggled on
That would match Nemo's behavior, while also being the simplest to implement.
If so, I believe I'm ready to send the MR. :))
Though I can't fork the repo. Permissions??
Check thunar_application_open_window.
Right, tnx!!! It was (now painfully) obvious 😅
For the hidden xfconf value....
Btw, if I'm not bothering you for a quick explanation, is the "nick" parameter in g_param_spec_xxx used for anything, or it's just a "pretty name" (grep doesn't find it anywhere except in the definition itself)??
And is it needed for the split view prop in particular?
Though just to reiterate and make sure we're on the same page:
misc-always-enable-split-view TRUE:
First and all subsequent windows have split view
Fully agree. Though maybe the name of the setting could be tweaked, since it is still possible to disable split view with F3. How about misc-open-new-windows-in-split-view ?
misc-always-enable-split-view FALSE:
All windows start with single pane, even if current one has split view toggled on
Fine for me, with an exception for restart: I think it would be good to keep the current behavior for restarting thunar. So if split-view was used when thunar was quit, it as well will be active on the next start.
Though I can't fork the repo. Permissions??
Fixed, now you can fork !
Btw, if I'm not bothering you for a quick explanation, is the "nick" parameter in g_param_spec_xxx used for anything, or it's just a "pretty name" (grep doesn't find it anywhere except in the definition itself)??
And is it needed for the split view prop in particular?
The second element is the property’s nick name, which is a string with a short description of the property. This is generally used by programs with strong introspection capabilities, like the graphical user interface builder Glade.
Actually after reading the paragraph, I still have no idea :D ... of course introspection as well can be done with thunar, as if glade would have a special role for that. So ¯\_(ツ)_/¯ .. best just do the same like the other properties.
Though maybe the name of the setting could be tweaked...
As far as I'm concerned it can literally be anything :D
But since the name obviously ought to make sense for everybody, thinking about misc-always-enable-split-view vs. misc-open-new-windows-in-split-view makes me conclude that neither fits "perfectly".
You're right about first getting potentially implicated to F3/toggle functionality (which it shouldn't), while the latter "misses" on the fact that the option also applies to the first/initial window opened.
So, perhaps misc-always-start-with-split-view, or something along that line, would be the best, since it implies having effect on both the first and all subsequent windows (incidentally, it also matches the wording of Nemo's preference: "Always start in dual-pane view")?
Fine for me, with an exception for restart: I think it would be good to keep the current behavior for restarting thunar. So if split-view was used when thunar was quit, it as well will be active on the next start.
Agreed.
I'm getting pretty brain dead right now, so I could be mistaken, but if I'm not, this should actually cover both cases:
/* thunar_application_open_window() *//* enable split view, if preffered */g_object_get(G_OBJECT(application->preferences),"misc-always-enable-split-view",&always_enable_split_view,NULL);g_object_get(G_OBJECT(application->preferences),"last-restore-tabs",&restore_tabs,NULL);if(always_enable_split_view&&!restore_tabs)thunar_window_notebook_toggle_split_view(THUNAR_WINDOW(window));
Since if last-restore-tabs is on, Thunar does actually restarts with split view (and obviously, calling the split view toggle with "restore-tabs" enabled defeats both)!
I didn't know that until now (since I wasn't using the "restore tabs" option). 🤦😃
Anyhow, I'll test it properly tomorrow with a fresh mind, to make sure no current behavior gets changed! :))
Fixed, now you can fork !
Tnx! 🍻
Regarding "nick name", I was reading about it in Gtk docs (for C), but no mention of introspection there... Anyway, it does make a bit more sense now, tnx!
best just do the same like the other properties.
Well, that's why I've asked in the first place, since some props have it, some don't, with no obvious distinction as to why :DDD
I guess it won't do any harm to leave it present then (not "NULL")...
But since the name obviously ought to make sense for everybody, thinking about misc-always-enable-split-view vs. misc-open-new-windows-in-split-view makes me conclude that neither fits "perfectly".
You're right about first getting potentially implicated to F3/toggle functionality (which it shouldn't), while the latter "misses" on the fact that the option also applies to the first/initial window opened.
One could argue that as well the first window is a new window 😄
but if I'm not, this should actually cover both cases: