Looking at defaults.list there are a few apps we don’t ship with (totem, eog, nautilus, evolution, thunderbird, shotwell) that needs replacing with the associated apps .desktop file (/usr/share/applications)
So all of this needs to be done - carefully tested … and then we can think about shipping a stable release update to 20.04
I fail to see how that would have to do with a bug of file-roller.
It seems to me as just a wrong file-extension-to-app association. This has to be defined by default at OS level, isn’t it? Otherwise it would also be a debian problem (if it is, let me just shut up).
I would also advice gdebi over the software installer to install .deb files. At least for advanced users.
It’s lighter for a simple package (including a couple of dependencies). And a better complement to Synaptic. I’ve never used the software installer as it is a bit light-featured yet bloated for my usage.
The method I out-lined above (defaults.list) resolves this properly for all users.
File-roller devs have decided they want to “service” .deb files. In the real world we don’t want this. So its a question of how to “override” what the devs want - so the method about defaults.list is the method we should use control how we as a distro want to handle files
Allright I will test. Noticed it’s snap-store_ubuntu-software-local-file.desktop that probably needs to be changed to gnome-software-local-file.desktop
To replace all other stuff that is assigned to non-Budgie apps, where can I find the list of application names?
For example org.gnome.Totem.desktop should be replace by something.celluloid.desktop
Here you go, copied /usr/share/applications/defaults.list and made the changes in 1 go.
The changes I made, as shown in GitHub diff: snap-store_ubuntu-software-local-file.desktop > gnome-software-local-file.desktop org.gnome.Totem.desktop > io.github.celluloid_player.Celluloid.desktop org.gnome.eog.desktop > org.gnome.gThumb.desktop shotwell.desktop > org.gnome.gThumb.desktop gimp.desktop > org.gnome.gThumb.desktop banshee-audiocd.desktop > rhythmbox-device.desktop org.gnome.Nautilus.desktop > nemo.desktop thunderbird.desktop > org.gnome.Geary.desktop
Note: I skipped Evolution as I thought that specific entry is some sort of PIM, not sure if it should be Geary (or just removed if there is no app for it in Budgie).
/offtopic
I will probably create one for myself to have Pluma instead of Gedit, Audacious instead of Rythmbox (lacks folder view).
We’ll add this into 20.10 for its release. Then after a couple of months of good testing by everyone via the release in October we’ll do a SRU for 20.04 around december time ready for the 20.04.2 release.
Notice JPGs open in Drawing by default, this is quite annoying!
I didn’t even realize it was a different program, just thought gThumb looked weird and kinda useless.
For example: open a photo, you will start with an extremely zoomed in view of a portion of your photo. And there is nothing obvious you can do to see your full photo.
I have to say Budgie 20.04 is quite disappointing from a new user perspective, as software files don’t open as a regular person would expect and the same goes for photos. There isn’t even a way to look at your photos normally, as a new user doesn’t know about the existence of gThumb.
It’s not a massive bug as we have already figured out the solution, but it makes it quite annoying to use for basic users. Just wanted to point that out.
I was recommending Budgie everywhere but I think ppl are better off waiting till October for 20.10.
surely simple enough to open with a preferred application or change personal defaults as an individual, pretty sure this applies to all operating systems…
When someone double clicks on a JPEG, he or she expects to see the photo. This is impossible with Budgie 20.04. but IS possible with Budgie 19.04 and 19.10.
Nothing correct about that. Try any other Ubuntu flavour and you can see a photo when you double click on it. Which is the expected behaviour.
@jesssullivan
This is what happens in UB 20.04 when I double click a JPEG file. On any consumer OS, the photo would be shown. I see some vague canvas, can’t even be sure it’s part of my photo. And there is nothing I can do here in this program, nothing obvious anyway, to show my photo. I have to know, I need to associate JPEG to a different program. But then I also have to know an alternative program exists.
Let me reiterate. This is a bug. It will be fixed in due course in 20.04 once we have confirmation that the changes haven’t caused further regressions.
