#164 Remove Photos from the default apps
Opened a year ago by aday. Modified a month ago

At today's WG meeting, we decided to remove Photos and Rhythmbox from the default app set, so they're not included in the install media. The main rationale for this: it's increasingly uncommon for users to have local music and photo collections.

I don't think that there's a rush to do this, and it might be good to pause and see if the community has any input before we procede.

We also ought to think about and test the UX for playing a standalone audio file. Is Videos sufficient here?


We also ought to think about and test the UX for playing a standalone audio file. Does Videos sufficient here?

I think Videos is sufficient if we rename it to something more generic, like Media Player. Otherwise, removing Rhythmbox will result in Videos becoming the default music player. We already have gedit as our default calendar application, and should probably avoid creating a second strange default.

how does renaming it avoid the strange default ?

"Media" would refer to both music and videos. At least, I don't think it would be strange to have a "media player" as the default music player.

but the totem ui is still quite weird for playing music

True, nowadays it just displays a black background when playing music. It used to display a musical note icon. I'm sure other design improvements would be possible.

Maybe we need further discussion here. Removing Rhythmbox is something that should be done with full understanding that it means promoting Videos to be the default music player, which does seem pretty weird.

Rhythmbox isn't really designed to play a standalone audio files either. Testing here, the window pops up and it starts "adding tracks to library" (with a progress bar), without actually playing the file.

Screenshot_from_2020-07-21_19-47-45.png

To be clear: I think we should get rid of Rhythmbox, because I agree it's not designed to meet our needs for a music player. But if we wind up with Videos as the default music player, we have failed just as surely as we have with gedit being our default calendar....

Clearly it is a bit odd to have Videos as the default handler for audio files - the UI isn't suited to it, and there's cognitive dissonance having "Videos" play audio.

However, I'm not really sure that this is an important enough case on which to base a decision about default apps. We're just talking about a default fallback for odd cases - if someone is going to play a lot of audio, I think we expect them to install another app which better meets their needs.

Furthermore, our options here are somewhat limited. There's Sushi, but I have some real doubts about that, and would actually be interested in removing it. Or we could do a basic, simple audio app, but I don't think that's really interesting to expose to users. Or we could teach Music to open files, but I'm not sure that development is active enough, and we've historically had quality issues with that app.

I'm OK with removing sushi. If we're going to do that, let's do so now, before GitLab reorganization. Let's try to make as many of these decisions as possible before GitLab reorg.

However, I'm not really sure that this is an important enough case on which to base a decision about default apps. We're just talking about a default fallback for odd cases - if someone is going to play a lot of audio, I think we expect them to install another app which better meets their needs.

I dunno. Maybe? totem would be pretty decent if renamed; the only tweak I can think to suggest would be to display some fallback icon when the album has no album art. I'd also be OK with keeping Music and teaching it to open files. I agree this app has had many quality issues in the past, but it seems to be decent now. Removing it makes sense to me to cut down on our workload. But it probably doesn't make sense if we wind up with Videos as the default music player?

Brainstorming: maybe we could have a baseline goal of having a reasonable default app assigned to the content types that we expose in the Default Applications panel of System Settings? Currently that is: Web (Firefox), Mail (none, looks broken), Calendar (gedit), Music (Rhythmbox), Video (Videos), Photos (Image Viewer).

I discussed this with the upstream design team last week, and there was a consensus that it's OK to rely on Videos as the default audio handler.

I think we should consider this for F33.

Metadata Update from @aday:
- Issue set to the milestone: Fedora 33

a year ago

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

a year ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting

a year ago

At today's WG meeting, we decided to remove Photos and Rhythmbox from the default app set, so they're not included in the install media. The main rationale for this: it's increasingly uncommon for users to have local music and photo collections.

This was already approved a month ago, but we approved it again today. ACTION: aday to talk to rishi, mcatanzaro to update comps

totem is NOT a music player. It wasn't designed to be a music player, and we (I) have actively removed features that would make it better as a music player because it's hard enough for it to be a movie player without putting on the burden of being a decent music player as well.

I'm not even happy about the state of disrepair of infrastructure that totem needs to be using to be mildly capable on Fedora. gnome-software/PackageKit have had broken codecs installation for years, and I really don't want to have to deal with bug reports about first-time play back of AAC files being broken because of this.

I discussed this with the upstream design team last week, and there was a consensus that it's OK to rely on Videos as the default audio handler.

I wasn't contacted or consulted on this unfortunately, either as the upstream or downstream maintainer.

I'm OK with removing sushi. If we're going to do that, let's do so now, before GitLab reorganization. Let's try to make as many of these decisions as possible before GitLab reorg.

Sushi isn't a default handler for any file formats, it's the quickview window you get when you press space on a file in nautilus. Why would you want to remove it?

I discussed this with the upstream design team last week, and there was a consensus that it's OK to rely on Videos as the default audio handler.

I wasn't contacted or consulted on this unfortunately, either as the upstream or downstream maintainer.

Sorry, we didn't anticipate that it would be an issue for you. Nothing's been committed yet, and I'd be happy to talk it over before there are any changes.

Sorry, we didn't anticipate that it would be an issue for you. Nothing's been committed yet, and I'd be happy to talk it over before there are any changes.

Videos is a movie player, and it's undermaintained. Rhythmbox works fine apart from small buglets (like the one you've seen earlier in the thread, and that's fixed in the Flathub Flatpak, and in the upstream repository).

Making Videos the default music player isn't going to free up any time for anyone to make Videos a better music player (not that I'd want to), or find/make/enhance/fix a replacement music player. It doesn't make the user's experience better either.

Rhythmbox works fine apart from small buglets (like the one you've seen earlier in the thread, and that's fixed in the Flathub Flatpak, and in the upstream repository).

What fix is that and can you fix that in the Fedora packaging as well, please? (I don't see any patches being applied in the flathub packaging by the way.)

Rhythmbox works fine apart from small buglets (like the one you've seen earlier in the thread, and that's fixed in the Flathub Flatpak, and in the upstream repository).

What fix is that and can you fix that in the Fedora packaging as well, please? (I don't see any patches being applied in the flathub packaging by the way.)

You're right, the fix in question (https://gitlab.gnome.org/GNOME/rhythmbox/-/merge_requests/10) is in 3.4.4 already.

Ah, great :) Thanks for checking!

$0.02: If we want to have a separate music app in addition to totem, it should be gnome-music, which works well. But gnome-music cannot open music files, so it cannot be the default music player.

Rhythmbox will do the wrong thing when opening music files: it will try to add the file to your music library even though that's normally a nonsensical thing to do, instead of just playing the file. So even if we were to keep Rhythmbox, totem is sadly still the better choice for default music player, since it will just play the music file rather than trying to do strange database things.

I get the impression that few people are particularly satisfied with this situation, but nobody seems to have any strong counterproposal either, and it seems nicer than the status quo. At least I'm quite anxious to remove Rhythmbox.

I've cleaned up a patch I had started work on a year ago that removes the association between totem and audio files, and merged it for the next stable release, so that option just won't be there:
https://gitlab.gnome.org/GNOME/totem/-/merge_requests/158#note_894637

I don't think removing Rhythmbox is suddenly urgent when there's no good replacement for it. If Rhythmbox trying to add the file to its database before playing it isn't wanted, what's to say that Music won't behave the same way?

@aday Back to the drawing board?

@hadess, upstream doesn't have Rhythmbox, so now we have no way to play audio files upstream....

@hadess and I had a chat about this earlier. I know he's interested in exploring the possibility of having a small, minimal media player app, potentially to replace both Rhythmbox and Videos in the default install.

I also understand that there is a lot of pressure around codec support and the general level of brokenness there.

I did consider creating a standalone simple media player as a replacement for Rhythmbox. I think my main concern there is that it would just inherent the existing problems that Videos currently has, including the codec support issues.

Videos is perfectly adequate as a default audio handler in my opinion. We don't need it to be a music player or be particularly adapted for audio playback - it just needs to work for the odd occasions when someone has a random audio file that they want to play. It's a fallback for use in unusual cases, nothing more.

That said, there's no burning urgency to remove Rhythmbox, so if we want to give this discussion more time then there's no serious harm in leaving it for this release.

I'm also starting to wonder about the direction of the default app set. Logs and Contacts are also a bit problematic, and it might be that we end up not shipping Boxes by default soon too. We could end up in a situation where we don't have very few default apps left. That deserves thought. I'm also wondering whether having a Videos app but no Music could look a bit odd.

I would say we shouldn't do this at all, and just have a separate issue for transitioning from both Videos and Rhythmbox to a new minimal Media Player application if and when it exists.

Logs and Contacts are also a bit problematic

Let's add these proposals to https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/150 if you want to go through with removing them.

and it might be that we end up not shipping Boxes by default soon too

Ah yes, we just did that upstream in https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/290 but I forgot to create a downstream issue here.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

a year ago

Agreed: defer action to F34.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue set to the milestone: Fedora 34 (was: Fedora 33)

a year ago

I think we should probably drop the proposal to remove Rhythmbox. While it's relatively unusual to manage local music collections nowadays, it's not particularly damaging to include it, and there are a few reasons to keep it around:

  • If we have Videos pre-installed, it feels neater/more cohesive to have at least one other multimedia app.
  • It helps to stop the pre-installed app set from getting really small.
  • Other platforms generally seem to come with a music app by default, and there may be user expectations that there will be one.

I'd still be interested in removing Photos. The same arguments in favour of music can be applied to Photos, but Photos's featureset seems less relevant overall.

I think we could explore replacing Rhythmbox with Music, and it might be useful to draw up a list of requirements for us to make the switch.

Sorry in advance for bike-shedding this, but I feel that if we are simply offering Rhythmbox to cover the corner case where a user manages local music collections in 2020, we could just make Sushi more discoverable instead.

Users can play music files with Sushi, and if they want to have a collection and all, they would install a proper app.

The same for other content apps. You use Sushi to be able to preview these files in the default Fedora installation, and you can install an extra app yourself if you are looking into something more advanced than simply "preview".

I think we could explore replacing Rhythmbox with Music, and it might be useful to draw up a list of requirements for us to make the switch.

Music has been ready for several years now IMO. What requirements do you have in mind? It would be really nice if it could open audio files or index music outside ~/Music, but I don't think those are good reasons to keep Rhythmbox around.

Sorry in advance for bike-shedding this, but I feel that if we are simply offering Rhythmbox to cover the corner case where a user manages local music collections in 2020, we could just make Sushi more discoverable instead.

How would a user use sushi to open an audio file? It's going to need some sort of user interface that doesn't currently exist, right? And it would need to register MIME handlers for the file types that it can open, so it could be set as a default app in System Settings?

How would a user use sushi to open an audio file? It's going to need some sort of user interface that doesn't currently exist, right? And it would need to register MIME handlers for the file types that it can open, so it could be set as a default app in System Settings?

Yes and yes. I could work on this if desired.

... if we are simply offering Rhythmbox to cover the corner case where a user manages local music collections in 2020, we could just make Sushi more discoverable instead.

That wasn't actually one of the reasons I listed in my last comment - there are other factors worth considering in my opinion.

Music has been ready for several years now IMO. What requirements do you have in mind?

:point_right: #33

Let's use #33 to continue the discussion regarding Rhythmbox and Music, and leave this one for Photos. I've renamed the topic accordingly.

Allan, have your plans changed here? Still want to remove Photos? Have you talked to Rishi about this?

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

7 months ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

7 months ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: meeting-request

7 months ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request

7 months ago

Metadata Update from @catanzaro:
- Issue tagged with: default-apps

7 months ago

I did have a conversation with Debarshi about Photos back in April, where we talked about rebooting the Photos development effort, with a reduced set of design goals for the app. In the end the conversation petered out, though. I'll have a go at restarting it.

It feels like we're in a bind here: the WG has indicated that it would like to keep apps for music and photos included in the default install. Music at least gets a small amount development, Photos I haven't seen movement in a long time, and i'm not sure how useful it is in its current form.

Metadata Update from @aday:
- Issue set to the milestone: None (was: Fedora 34)

a month ago

Login to comment on this ticket.

Metadata
Attachments 1