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.

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.

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.

Agreed: defer action to F34.

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?

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.

I gave Photos another spin yesterday and managed to make it crash within a fairly short space of time.

I've created a new set of mockups for Photos, in an attempt to provide a direction for any development work. The upstream issue report for this is here.

I think that we should look again at this issue for F36; if there isn't any movement within the F35 cycle, I'd be inclined to remove Photos from the default install.

Note the equivalent upstream issue is: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/148

The WG seems inclined to not remove Photos. Instead, Matthias will find a volunteer (or perhaps "volunteer" ;) to help with a round of fixes and improvements.

The WG seems inclined to not remove Photos. Instead, Matthias will find a volunteer (or perhaps "volunteer" ;) to help with a round of fixes and improvements.

This was from the WG meeting on 2022-01-18. In addition to fixing up Photos, one thing that was discussed there was the desire to have simple image editing in the default image viewer. If we had that, then there might not be so much of a case for Photos.

The WG seems inclined to not remove Photos. Instead, Matthias will find a volunteer (or perhaps "volunteer" ;) to help with a round of fixes and improvements.

I think we should continue this in a separate issue, if desired. For now, Photos remains....

I've reopened this on the basis of the issues that have been found during F36 testing (see #304). We should re-evaluate the inclusion of gnome-photos for F37.

Has GNOME ever considered merging some apps? Like gnome-music with totem and gnome-photos with eog, for example. This might improve the app audience, increase testing and avoid fragmentation.

I'm going to suggest we hard punt on this, and defer to GNOME upstream decision. Currently we only have two divergences from upstream core apps: epiphany -> firefox and gnome-music -> rhythmbox. We don't need more divergence IMO, and except for the web browser, upstream goals for core apps pretty much exactly align with Fedora goals. So if we want to remove it, let's push that upstream.

The upstream ticket for this is: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/148

I would just remove it from core if we want to remove it, rather than have subcategories of core apps for "bad" apps that we don't really want.

Has GNOME ever considered merging some apps? Like gnome-music with totem and gnome-photos with eog, for example. This might improve the app audience, increase testing and avoid fragmentation.

No, it has not been considered.

Plan is for gnome-music and totem to remain independent.

Plan is for eog to be replaced by loupe.

No plan exists for gnome-photos. Nobody agrees on what to do with gnome-photos.

Has GNOME ever considered merging some apps? Like gnome-music with totem and gnome-photos with eog, for example. This might improve the app audience, increase testing and avoid fragmentation.

No, it has not been considered.

Plan is for gnome-music and totem to remain independent.

Plan is for eog to be replaced by loupe.

No plan exists for gnome-photos. Nobody agrees on what to do with gnome-photos.

Maybe the photo management could be moved to Nautilus? I remember seeing an issue in GitLab discussing about improving the default folders (photos, documents, videos, music, etc.) of Nautilus into something more, like transforming them into virtual folders, which can make the file search more better too.

Action agreed at meeting on 24 May 2022 - @catanzaro to talk to upstream and Fedora QA

The current status on this is: upstream is discussing the status of GNOME Photos. I expect this will not be completed within the F37 timespan. We are considering establishing a process to track removal of core apps more rigorously, but it's still unclear whether we want to put Photos through that process or not.

Currently Photos is undermaintained and might not survive the switch to libsoup 3, so the decision might be made for us on that basis.

The working group discussed this issue on August 17: https://meetbot.fedoraproject.org/fedora-meeting-2/2022-08-17/workstation.2022-08-17-02.53.log.html

My notes from that session state:

Photos is "fixed" to work in F37 by removing all the online accounts functionality. It's basically unmaintained upstream.
WG is ambivalent on the question of whether to remove Photos from the default apps. It might depend on whether there are blocker issues with it.

Action: Michael and Allan to complete upstream review process for Photos (likely to result in removal of Photos from GNOME core)

I've created this merge request to remove Photos upstream. Will wait for this to land before removing it from comps.

The pending action for this issue is for Photos to be removed from GNOME's core apps. @catanzaro is working on this.

This is complete.