It’s been a while since my big core app reorganization for GNOME 3.22. Here is a history of core app changes since then:
- GNOME 3.26 (September 2017) added Music, To Do (which has since been renamed to Endeavor), and Document Scanner (simple-scan). (I blogged about this at the time, then became lazy and stopped blogging about core app updates, until now.)
- To Do was removed in GNOME 3.28 (March 2018) due to lack of consensus over whether it should really be a core app. Â As a result of this, we improved communication between GNOME release team and design team to ensure both teams agree on future core app changes. Mea culpa.
- Documents was removed in GNOME 3.32 (March 2019).
- A new Developer Tools subcategory of core was created in GNOME 3.38 (September 2020), adding Builder, dconf Editor, Devhelp, and Sysprof. These apps are only interesting for software developers and are not intended to be installed by default in general-purpose operating systems like the rest of GNOME core.
- GNOME 41 (September 2021) featured the first larger set of changes to GNOME core since GNOME 3.22. This release removed Archive Manager (file-roller), since Files (nautilus) is now able to handle archives, and also removed gedit (formerly Text Editor). It added Connections and a replacement Text Editor app (gnome-text-editor). It also added a new Mobile subcategory of core, for apps intended for mobile-focused operating systems, featuring the dialer app Calls. (To date, the Mobile subcategory has not been very successful: so far Calls is the only app included there.)
- GNOME 42 (March 2022) featured a second larger set of changes. Screenshot was removed because GNOME Shell gained a built-in screenshot tool. Terminal was removed in favor of Console (kgx). We also moved Boxes to the Developer Tools subcategory, to recommend that it no longer be installed by default in general purpose operating systems.
- GNOME 43 (September 2022) added D-Spy to Developer Tools.
OK, now we’re caught up on historical changes. So, what to expect next?
New Process for Core Apps Changes
Although most of the core app changes have gone smoothly, we ran into some trouble replacing Terminal with Console. Console provides a fresher and simpler user interface on top of vte, the same terminal backend used by Terminal, so Console and Terminal share much of the same underlying functionality. This means work of the Terminal maintainers is actually key to the success of Console. Using a new terminal app rather than evolving Terminal allowed for bigger changes to the default user experience without upsetting users who prefer the experience provided by Terminal. I think Console is generally nicer than Terminal, but it is missing a few features that Fedora Workstation developers thought were important to have before replacing Terminal with Console. Long story short: this core app change was effectively rejected by one of our most important downstreams. Since then, Console has not seen very much development, and accordingly it is unlikely to be accepted into Fedora Workstation anytime soon. We messed up by adding the app to core before downstreams were comfortable with it, and at this point it has become unclear whether Console should remain in core or whether we should give up and bring back Terminal. Console remains for now, but I’m not sure where we go from here. Help welcome.
To prevent this situation from happening again, Chris and Sophie developed a detailed and organized process for adding or removing core apps, including a new Incubator category designed to provide notice to downstreams that we are considering adding new apps to GNOME core. The new Incubator is much more structured than my previous short-lived Incubator attempt in GNOME 3.22. When apps are added to Incubator, I’ve been proactively asking other Fedora Workstation developers to provide feedback to make sure the app is considered ready there, to avoid a repeat of the situation with Console. Other downstreams are also welcome to watch the  Incubator/Submission project and provide feedback on newly-submitted apps, which should allow plenty of heads-up so downstreams can let us know sooner rather than later if there are problems with Incubator apps. Hopefully this should ensure apps are actually adopted by downstreams when they enter GNOME core.
Imminent Core App Changes
Currently there are two apps in Incubator. Loupe is a new image viewer app developed by Chris and Sophie to replace Image Viewer (eog). Snapshot is a new camera app developed by Maximiliano and Jamie to replace Cheese. These apps are maturing rapidly and have received primarily positive feedback thus far, so they are likely to graduate from Incubator and enter GNOME core sooner rather than later. The time to provide feedback is now. Don’t be surprised if Loupe is included in core for GNOME 45.
In addition to Image Viewer and Cheese, we are also considering removing Photos. Photos is one of our “content apps” designed to allow browsing an entire collection of files independently of their filesystem locations. Historically, the other two content apps were Documents and Music. The content app strategy did not work very well for Documents, since a document browser doesn’t really offer many advantages over a file browser, but Photos and Music are both pretty decent at displaying your collection of pictures or songs, assuming you have such a collection. We have been discussing what to do with Photos and the other content apps for a very long time, at least since 2015. It took a very long time to reach some rough consensus, but we have finally agreed that the design of Photos still makes sense for GNOME: having a local app for viewing both local and cloud photos is still useful. However, Photos is no longer actively maintained. Several basic functionality bugs imperiled timely release of Fedora 37 last fall, and the app is less useful than previously because it no longer integrates with cloud services like Google Photos. (The Google integration depends on libgdata, which was removed from GNOME 44 because it did not survive the transition to libsoup 3.) Photos has failed the new core app review process due to lack of active maintenance, and will be soon be removed from GNOME core unless a new maintainer steps up to take care of it. Volunteers welcome.
Future Core App Changes
Lastly, I want to talk about some changes that are not yet planned, but might occur in the future. Think of this entire section as brainstorming rather than any concrete plans.
Like Photos, we have also been discussing the status of Music. The popularity of DRM-encumbered cloud music services has increased, and local music storage does not seem to be as common as it used to be. If you do have local music, Music is pretty decent at handling it, but there are prominent bugs and missing features (like the ability to select which folders to index) detracting from the user experience. We do not have consensus on whether having a core app to play local music files still makes sense, since most users probably do not have a local music collection anymore. But perhaps all that is a moot point, because Videos (totem) 3.38 removed support for opening audio files, leaving us with no core apps capable of playing audio for the past 2.5 years. Previously, our default music player was Videos, which was really weird, and now we have none; Music can only play audio files that you’ve navigated to using Music itself, so it’s impossible for Music to be our default music player. My suggestion to rename Videos to Media Player and handle audio files again has not been well-received, so the most likely solution to this conundrum is to teach Music how to open audio files, likely securing its future in core. A merge request exists, but it does not look close to landing. Fedora Workstation is still shipping Rhythmbox rather than Music specifically due to this problem. My opinion is this needs to be resolved for Music to remain in core.
It would be nice to have an email client in GNOME core, since everybody uses email and local clients are much nicer than webmail. The only plausible candidate here is Geary. (If you like Evolution, consider that you might not like the major UI changes and many, many feature removals that would be necessary for Evolution to enter GNOME core.) Geary has only one active maintainer, and adding a big application that depends on just one person seems too risky. If more developers were interested in maintaining Geary, it would feel like a safer addition to GNOME core.
Contacts feels a little out of place currently. It’s mostly useful for storing email addresses, but you cannot actually do anything with them because we have no email application in core. Like Photos, Contacts has had several recent basic functionality bugs that imperiled timely Fedora releases, but these seem to have been largely resolved, so it’s not causing urgent problems. Still, for Contacts to remain in the long term, we’re probably going to need another maintainer here too. And perhaps it only makes sense to keep if we add Geary.
Finally, should Maps move to the Mobile category? It seems clearly useful to have a maps app installed by default on a phone, but I wonder how many desktop users really prefer to use Maps rather than a maps website.
GNOME 44 Core Apps
I’ll end this blog post with an updated list of core apps as of GNOME 44. Here they are:
- Main category (26 apps):
- Calculator
- Calendar
- Characters
- Cheese
- Clocks
- Connections
- Console (kgx)
- Contacts
- Disks (gnome-disk-utility)
- Disk Usage Analyzer (baobab)
- Document Scanner (simple-scan)
- Document Viewer (evince)
- Files (nautilus)
- Fonts (gnome-font-viewer)
- Help (yelp)
- Image Viewer (eog)
- Logs
- Maps
- Music
- Photos
- Software
- System Monitor
- Text Editor
- Videos (totem)
- Weather
- Web (epiphany)
- Developer Tools (6 apps):
- Boxes
- Builder
- dconf Editor
- Devhelp
- D-Spy
- sysprof
- Mobile (1 app):
- Calls
This article sounds more like there is a resourcing problem within GNOME rather than a problem of determining what goes into Core.
Perhaps, we should look at it from a resourcing perspective. With the rapid growth of 3rd party GNOME applications on Flathub, more and more developers are getting comfortable with GTK/libadaitwa.
I wonder if the GNOME Foundation can fund some initiatives to further provide a clear and easy track to enable those developers to start becoming Core contributors. The current documentation around contributions is way too high-level and basic. This leads to a huge hurdle in becoming a Core contributor.
Another way is to at least promote a fundraising campaign similar to the patent defense lawsuit a few years ago to bring in resources to fund updates to applications like Photos and Music.
It seems that Gnome Shell no longer shows results of document contents since Documents is gone.
However, Nautilus still searches contents, so I think Tracker indexing has not changed.
Hi, you added an extra “)” in the link to the Music merge request link. As a result Gitlab shows a login screen.
Fixed, thanks.
Hi, I wrote the original PicasaWeb (Google Photos) support for libgdata under guidance from Philip Withnall back in 2009. I’m sad to hear that it’s no longer in use. If there is interest, I’d be happy to try to make some of the necessary update for libgdata as I’m currently looking for projects to contribute to. (And soup is delicious.)
About some of the other apps experiencing issues, I’ll note that the extent of some of their simplicity has prevented them from being useful at all to me as a user. I’d possibly like to help with those (e.g. Music) if there was support for letting them be more useful.
Hello, I’m also interested in working on getting libgdata functional again. Perhaps we can work on this together, is there somewhere better we can continue the discussion such as Matrix.
Thanks for your interest in helping libgdata. Probably best to start in #gnome-hackers:gnome.org
Hi, thanks for your interest in helping out.
To save libgdata we need to land this merge request, which is not ready: https://gitlab.gnome.org/GNOME/libgdata/-/merge_requests/28. libgdata also really needs a new maintainer as Philip understandably does not have time for it anymore. Saving libgdata would be a big help (it also powers the Google Drive integration in nautilus, for example, which is no longer available upstream but which distros are still shipping). But of course that wouldn’t be itself sufficient to save Photos.
As for Music, I think lack of a few key features has significantly reduced user interest in the app relative to other music players. E.g. anyone who keeps music outside ~/Music does not care about this app because it’s hard to make it work for them. I’m pretty sure we have an issue report somewhere where this is discussed and our designers showed interest in adding several new features, including a volume control (yes, really). But I cannot find the issue. Anyway, Music still has maintainers so you would want to talk to them about this, but I expect they would welcome assistance in improving Music.
As a more than 20 years gnome user, I realize than I don’t use (and even install) more than a half of what is in core. And, for a half of what I’m using, I wouldn’t say they are ‘core’ to a desktop. So why call them ‘core’?
And for man power, flatpak distribution gives more freedom to developers with easy and direct delivering of the software. So why would they spend time and energy to ‘bless’ them as core with all the contraints and loss of design freedom it comes with?
As pointed out by one of commentators, resource allocation seems one of big problem inside GNOME development. It is sad to read about the GNOME Photos state because of its potential. Currently, roughly twenty merge requests need resolving while useful information like date and more should be available for day one similar to Gallery app found on mobile devices and some OEM desktops. Will it be possible to get a new maintainers to address these opening tickets? If a maintainer is unfamiliar with codes, will they get a needed assistance?
Re: the importance of an email client and Geary having only one maintainer:
How different is Geary’s fork, Elementary Mail, at this point? Would it be a feasible candidate for GNOME core?
Especially given the limited resources, I think far more simple Music/Videos apps would make sense for core. I’ll focus on Music here since it has some clear potential replacements (or at least a model for a replacement app, if the maintainers don’t want to add to core) Something like Amberol/G4Music arguably does the basics far better than Music for people who just want to play local audio files, or maybe do basic management of a collection of music. The whole point of core apps is to provide basic functionality, and Music does way more than that, while missing some key functionality and having a bit of an odd design (due to technical limitations, I understand). If we wanted to provide all the tools for the now-relatively-niche use case of a local music collection, that would imply including tagging software, etc. Surely, like music tagging software, Music would be far better as a Circle app, with an easier-to-maintain, simpler app in core?
As for general resources problems, it might be helpful to add a list of apps needing more resources across multiple channels (apps.gnome.org, discourse, social media), with links to getting started, so that people with some skills who might not ordinarily contribute to core apps and thus not follow the inner workings of GNOME development enough to know if a project has a resource issue – I consider myself a relatively engaged user, but I had no idea that Photos and Contacts needed more maintainers./contributors. I unfortunately have no interest in contributing them as I don’t use them, but I’m sure there are some people who just haven’t been reached.
For me, I have the problem that Photos is neither good enough to manage a photo library (in the sense of the featureset provided by e.g. even Google Photos on the Web; I need to keep Shotwell installed), nor as an image browser (extra complexity, overlap with eog/loupe).
The same goes with Music. I do have a big music library, and the experience provided by it is not good. It also lacks proper lyrics management, integration with online services such as listenbrainz, etc. Rhythmbox has an interface out of the ’00s, but at least it works. So my go to app is Lollypop.
In my mind the question is: should GNOME really stick with subpar applications just because they strictly adhere to the HIGs, or due to some other (to me) unclear decisional process, or should it maybe just recognize that we might want to just select a first-tier app that already exists and give it a bit more development love to have Gtk4 support, cleaner interface, etc.
So for me, Lollypop and Shotwell are the best current replacements in terms of functionality, though the UI might not adhere to expectations.
Why do we keep fragmenting our limited resources in a gazillion projects? Seems from this blog post, there aren’t that many resources to begin with…
“Why do we keep fragmenting our limited resources”?
Because volunteer work is not fungible, and volunteers work on what they want to work. It’s not like the release team or the design team can tell people to go to work on something, and people will do it.
I love Console’s UI and keyboard shortcuts, hope it won’t be replaced by Gnome Terminal