My OS is Fedora 39 Workstation.
The goal is to use Files 42 running out of a distrobox container.
The steps I have taken :
how can I add the apps in the host system to the context menu?
would packaging Files 42 as a flatpak work?
Yes, that’s that what would happen when running a file manager in a container; it only sees the apps installed in that container. A flatpak would work within the (substantial) limitations of a sandboxed file manager. Instead of being able to pick the app used to open a file directly, it would delegate to the OpenURI portal.
Out of curiosity, what aspect of nautilus 42 are you trying to preserve?
Right, so can I make the host binaries/.desktop files visible to the app in the container somehow?
Can distrobox use an “OpenURI portal”?
I tried this with distrobox as it was quick and easy, but I’m happy to work within the restrictions of a flatpak file manager based on using flatpak Dolphin, so I’ll carry on with this path. I’m not a developer so the going is slow, but it’s good know this method is going to work.
I’m also attempting to build and install Files 42 on Fedora 39, as I can install something like Thunar from rpm, and it works fine, I don’t see there any reason it cannot be made to work correctly. I’m thinking I can give the Files 42 binary a new name, “Kursk”, so to be able to run both old and new versions at the same time.
I want Files 42 as it is the last release that had working expandable folders, without which I won’t choose to use Nautilus. Files 45 is unusable due to a bug that doesn’t update the view correctly when documents are moved or copied. You can press F5 to reset, however this isn’t a reasonable solution.
I have been using Nemo instead. I do much of my work in the file manager and need the feature.
Having Files 42 on Fedora 39 and future releases will allow me to run the latest Fedora/Gnome with a trusted native file manager.
Not easily because the code in nautilus detects when its running in flatpak. That is moot though, because the portal integration is new in version 45: Improve file opening experience while sandboxed (!1204) · Merge requests · GNOME / Files · GitLab
Even if you did something like adding /run/host/usr/share to XDG_DATA_DIRS inside the container, it wouldn’t work properly because the apps would be launched inside the container instead of on the host (except for DBusActivatable ones, I guess). You’d need to copy the .desktop files (e.g. into /usr/local) and modify them to invoke flatpak-spawn --host.
DBusActivatable
Ah, saw this was deactivated in the firefox .desktop file, because it “Makes KDE crash”.
So I’ll turn that on, see what it does, and try to up my knowledge on this, xdg desktop, portals, and .desktop files spawning stuff. The portals thing reminds me of flash fscommand back in the 00s. Hello from Flash! This container business goes strange loop real quick.
I actually solved all my problems by just installing everything I need into distrobox, and running everything out of that, having the benefit I guess of being portable. easier to back too.
many thanks for the pointers.
Hello.
Please file a bug report about this. Or, if one already exists, please upvote it with the 
button.
I think getting the bug fixed would be the best workaround and I would like to help with that.
Hello,
Yes it would be amazing to get it fixed, it drove me crazy, I’m afraid I can’t give up folder trees after decades of using Directory Opus so I switched to nemo. But then I learnt about distrobox, and have a dubious solution that runs 42 out of a box. Works, but a bit janky. Interesting way of working though. Nice for backups.
I filed a bug report here :
And I just installed the nightly, and can recreate the behaviour here :
Also, and I wonder if this is a related thing, it’d be fabulous too if the history would store the folder I’ve just opened in treeview, in the same manner as double clicking to open. So the history would be the history of selected objects.
Currently history only stores folders that are double clicked to open, but using treeview, I might have opened a very complex structure, and it’s lost when I press F5 to reload ( because of the duplication bug).
In fact navigating forward or back loses that structure entirely. Which is annoying because that’s actually the work, creating that view into the data I have, that was part of the work. Be lovely to snapshot that expanded folder structure. In fact I don’t use the history because of this behaviour.
cheers!
Thanks.
Sorry, I have some backlog and haven’t reached that issue yet. But I can reproduce it! It should be possible ro fix when someone finds the time (not me in the next couple of weeks, but maybe me in april).
The other point is unrelated. I’m not sure if it’s already reported, but, yes, I think which subfolders were expanded is a state which should be stored in history, the same way we store which files were selected.
Meaning, that expanded folders are not expanded should be considered a shortcoming of the feature and a report is welcome if none exists yet.
I think history itself should still be only for thinks beijg double clicked, but if we were restore expansions and scroll to the last expanded folder that should be basically enough, right?
sounds fantastic. I see you guys are busy as hell all the time from looking at the constant stream of git commits, so it’s just good to know it’s on the radar and not just some weird thing happening on my system. I wondered if it might be due to partitions or selinux or something, maybe hardware.
I’ll look forward to dumping my janky workarounds. I even tried KDE at one point.
regarding the file history thing, restoring expansions would be great. I see what you mean regarding proper formal designs and process and whatnot, given the massive surface of Files and Gnome, and the people working on it , well it’s very daunting coming at it from ground zero, I can see the need for hard clear documentation and designs and structure and all those kind of things.
anyway thanks for taking the time to look at this, much appreciated.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.