GDM Settings gives the GNOME login manager a graphical settings app
A settings app for GNOME's Login Manager, GDM
At a glance
- What is it?
- GDM Settings is a small Python application for configuring GNOME's display manager, built with LibAdwaita and shipped as an AppImage or a Flatpak. The repository itself documents little, so the interesting part for an adopter is what the build files, the translation setup and the release history tell you about how the project is put together.
- Who is it for?
- GDM Settings fits a Linux user on GNOME who wants to change login screen behaviour without editing GDM configuration files by hand, and who is comfortable running a Flatpak or an AppImage. Skip it if your system runs LightDM or SDDM, since the project targets GDM only, or if you need a packaged release from your distribution rather than a downloaded artifact.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A configuration front end for one specific display manager
The project describes itself in one line as a settings app for GNOME's Login Manager, GDM. That constraint is the whole scope. It is not a general desktop configuration tool, and it is not a theming engine for the login screen in the sense of a wallpaper and colour scheme editor, it is a settings application for the display manager that GNOME ships with.
The technology choice follows from that. The README states the implementation language and the toolkit in a single line.
<p>It is written in Python and uses LibAdwaita for graphical interface.</p>The repository topics corroborate that with `gnome`, `gdm3`, `gtk4` and `libadwaita`, along with `gnu-linux` and `customization`. LibAdwaita and GTK4 matter for a practical reason: the app is expected to look like a native GNOME application, and adopting LibAdwaita is a way to inherit that look without reimplementing a widget set.
The project is distributed under AGPL-3.0, with the licence text in the `LICENSE` file at the top of the tree. For an application you run on your own machine that is a non-issue, and it only matters if you plan to modify and redistribute it, which is the situation the AGPL is written for.
The homepage is a GitHub Pages site at gdm-settings.github.io, and the README links to a wiki, a screenshots page and a donation page, all of which live outside the repository.
The build system and packaging tell you how the project ships
The top-level entries describe a fairly conventional GNOME application layout, and reading them tells you more about the project than the README does.
The Meson build is the primary build system, with a `po/` directory for translations, `data/` for the desktop entry and application resources, `resources/` for the interface assets, and a `subprojects/` directory for vendored dependencies. The main script is `gdm-settings.py.in`, where the `.in` suffix means it is a template that the build fills in, typically with the version and installation paths, and the Python package itself lives in `gdms/`.
Packaging is handled at the two ends of the distribution range. There is an `appimage/` directory for the AppImage build and a Flatpak manifest yaml file at the top level, named for the application id, which is a Flatpak manifest, since the name follows the reverse domain convention with the application id `io.github.realmazharhussain.GdmSettings`. The README carries a Flatpak download badge using that same application id.
There is also an `enter_temp_install.sh` script in the root. The README does not describe what it does, so its purpose is not documented anywhere in the repository, and it is worth reading before running it.
A `NEWS` file sits alongside the README, which is where release notes for a desktop application conventionally live, and the `.github/` directory holds the issue and contribution templates, since the README links to a bug report template with a specific label.
Two ways to get it running
The README offers a download and an install path, and the download is a single file.
<a href="https://github.com/gdm-settings/gdm-settings/releases/latest/download/GDM_Settings.AppImage">Download</a>The AppImage is attached to the latest release, so the link always points at the newest published artifact rather than at a fixed version. An AppImage is a self-contained bundle that you make executable and run, which suits a quick test on a machine where you do not want to touch system packages.
The second route is the Flatpak, identified by the application id named in the manifest file, which the README links to through a Flathub download badge. The Flatpak route is the one that integrates with a normal GNOME installation, since the desktop entry, the icon and the translations are handled by the packaging rather than by the user.
The README also points to a wiki page titled Install, and the fact that installation is documented on a wiki rather than in the repository is itself informative. The repository is a build source tree, and the operational instructions live alongside the community contributions.
What the README does not do is list the settings the app exposes. There is no feature list and no description of individual panels, so a reader cannot tell from the repository what GDM options are covered. That information has to come from the screenshots wiki page or from running the application.
Translations are contributed through Weblate
The project has a translation setup, and it is the part of the repository with the most visible external integration. The README carries a Weblate badge pointing at a hosted project named gdm-settings, and a separate Translate link to the same service, and the `po/` directory at the top of the tree is the gettext catalogue that Weblate operates on.
The arrangement is worth understanding if you want to contribute a language. You do not edit the `.po` files directly, you go to the Weblate project, and the translations come back into the repository through that service. The badge in the README reports the translation status.
For an adopter, the relevant question is coverage. A missing translation means the interface falls back to English for that locale, and the gettext catalogues in `po/` are what supply the translated strings. The README does not list which locales are complete, so the Weblate status page is the place to check before recommending the app to a user whose language is not covered.
The desktop integration also depends on the packaging rather than on the code, which is why the Flatpak is the more complete route for a translated installation.
Releases stopped in 2024 while commits continued
The release history and the commit history tell different stories, and the difference is worth noting before you pin a version.
The tagged releases are v4.4 on 2024-05-08, a v5.beta0 on 2024-11-06 and v5.0 on 2024-11-27. The last push was on 2026-10-04, and the repository is not archived. So the newest published release is nearly two years old, while the source tree has moved since then, in October 2026.
That gap is the practical risk in this project. If you take the AppImage from the latest release you get the 5.0 code as it was tagged, and if you build from `main` you get something newer that has not been through a release. The README does not say whether the current `main` is a pre-release of the next version or a stable branch being patched, and it does not document a supported channel for users who want fixes without moving to a new major version.
The presence of a `NEWS` file means the release history in text form is in the repository, and for a project at version 5.0 that file is the right place to look for what changed and when. A team that wants to run this in production should treat the version question as an open item rather than assuming the newest code is the safest choice, since the newest code is the least tested by definition.
The commits themselves are recent enough that the project is not abandoned, but recent commits and a recent release are different things, and only one of them is documented here.
What this app cannot do for you
Two limits are clear from the scope, and one is a documentation gap.
The first is that it only affects GDM. If your session manager is LightDM, SDDM or anything else, this application has nothing to configure, and the README does not mention support for other display managers. The same applies to the display manager you use on a machine that does not run GNOME, since the project is built against the GDM stack and the GNOME environment around it.
The second is that it is a settings front end, not a policy tool. It changes the configuration of a login manager on one machine. Anything that requires changing the display manager's own files, or applying the same configuration across a fleet of machines, is outside what a desktop settings application can do, and the README does not describe a configuration export or a command line interface for it.
The third is the documentation gap. The repository README is a landing page built from badges and links, with no feature list, no description of the individual settings, and no explanation of what each option does to GDM. The screenshots wiki page is the only visual documentation in the project, and the wiki is the only prose documentation. A reviewer who wants to know whether a specific GDM option is covered will have to install the app or read the wiki.
That is a normal state for a small desktop application with an active translation community, and it does not make the project a poor fit. It does mean the evaluation has to happen in the running application rather than in the repository.
Editorial conclusion
GDM Settings fits a Linux user on GNOME who wants to change login screen behaviour without editing GDM configuration files by hand, and who is comfortable running a Flatpak or an AppImage. Skip it if your system runs LightDM or SDDM, since the project targets GDM only, or if you need a packaged release from your distribution rather than a downloaded artifact. Verify first which artifact you will run, since the AppImage and the Flatpak id are the two routes the project offers, and read the wiki pages linked from the README before changing anything, since the repository documents the packaging and not the settings themselves.
Frequently asked questions
What is GDM Settings and what does it configure?
It is a settings app for GNOME's Login Manager, GDM, written in Python with LibAdwaita for the graphical interface. The README does not list the individual settings it exposes, so the coverage of specific GDM options is documented in the wiki and screenshots rather than in the repository.
How do I install GDM Settings?
The README offers two routes. The latest release page carries a downloadable AppImage, and a Flatpak is published under the application id `io.github.realmazharhussain.GdmSettings`. The README also links to a wiki page titled Install for the full instructions.
Which display managers does GDM Settings work with?
Only GDM, which is GNOME's login and display manager. The project description and the repository topics both refer to GDM and gdm3 specifically, and no other display manager is mentioned.
How is GDM Settings built?
The repository uses Meson, with `meson.build` at the top level, a `po/` directory for gettext translations, `data/` and `resources/` for application files, `gdms/` for the Python package and a `gdm-settings.py.in` template for the main script. An `appimage/` directory and an `io.github.realmazharhussain.GdmSettings.yaml` Flatpak manifest cover packaging.
How do I contribute a translation for GDM Settings?
Translations are handled through Weblate, which the README links to as a hosted project named gdm-settings, and the `po/` directory in the repository holds the gettext catalogues. The README carries a badge reporting the translation status of each language.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/gdm-settings-gdm-settings)Was this useful?