The login screen choice
You boot your Fedora machine after a fresh install and land on the GDM login screen. You click your username, type your password, and the desktop loads. Six months later, you watch a video about KDE Plasma widgets and decide you want that level of control. You install the KDE packages, reboot, and suddenly your GNOME extensions break, your terminal shortcuts vanish, and the system feels heavier than before. You are not alone. Switching desktop environments on Fedora is straightforward if you understand how the package manager groups them and how user sessions isolate configuration. It falls apart when you mix tools from both ecosystems without realizing they fight over the same defaults.
How Fedora actually handles desktop environments
Fedora ships with GNOME as the default desktop environment. KDE Plasma arrives as a separate spin or as a package group you pull in with dnf. They are not two skins for the same engine. They are entirely different software stacks with their own settings daemons, file managers, terminal emulators, and display server defaults. GNOME relies on gnome-shell, mutter, and dconf for configuration. KDE Plasma uses kwin, plasmashell, and kconfig. When you install both, the package manager installs both stacks side by side. The login screen simply asks which session wrapper to start for your user. Your home directory becomes a shared space. Configuration files in ~/.config/ and ~/.local/ start referencing tools from the environment you just installed. The system does not magically merge them. It runs whichever session you selected at login.
Under the hood, Fedora uses systemd --user to manage desktop services. When you log in, the display manager starts a user session that loads the appropriate desktop environment. That session sets environment variables like XDG_CURRENT_DESKTOP and DESKTOP_SESSION. Applications read those variables to decide which settings backend to query. If you launch a GNOME app inside a Plasma session, it will still look for dconf values. If those values do not exist, the app falls back to its compiled defaults. This is why shortcuts, themes, and window behaviors feel inconsistent when you mix environments. The isolation is intentional. It prevents one desktop from corrupting the other. You just need to respect the boundary.
Run journalctl -xe after a failed login. The explanatory text and end-of-journal jump will show you exactly which service refused to start. Read the actual error before guessing.
Installing and switching safely
You need to install the desktop environment cleanly. Fedora uses package groups to keep the dependencies organized. Do not install individual packages like plasma-desktop or gnome-shell manually. Use the group commands. They pull in the correct set of utilities, themes, and default applications. The group names are stable across Fedora releases. They also ensure that future dnf upgrade --refresh commands update the entire stack consistently.
Here is how to add KDE Plasma to an existing GNOME installation without breaking your current setup.
# Install the KDE Plasma desktop group with all recommended utilities
sudo dnf group install "KDE Plasma Workspaces" --setopt=install_weak_deps=False
# --setopt=install_weak_deps=False prevents pulling in extra games and demos
# The group pulls in kwin, plasmashell, dolphin, konsole, and default themes
# Fedora resolves dependencies automatically and marks them as group members
After the transaction finishes, log out completely. Do not just switch users. The display manager needs to drop the current session and read the new .desktop files in /usr/share/wayland-sessions/ and /usr/share/xsessions/. Click the gear icon next to the password field on the login screen. Select Plasma (Wayland) or Plasma (X11). Enter your password. The session starts.
If you prefer KDE as your permanent default, you can change the display manager. Fedora uses systemctl to manage the boot target. GDM and SDDM are both available. Switching them does not remove the other. It just changes which service starts at runlevel 5.
# Disable the current display manager to prevent it from starting on boot
sudo systemctl disable gdm.service
# Enable SDDM so it becomes the default login screen for the next boot
sudo systemctl enable sddm.service
# Reboot to apply the change and verify the new login screen loads
sudo reboot
Convention aside: configuration files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. If you ever need to tweak display manager behavior, edit /etc/sddm.conf or /etc/gdm/custom.conf. Never touch /usr/lib/. Package updates will overwrite manual edits there.
Reboot before you debug. Half the time the session wrapper is still holding onto old environment variables.
Verify the session is running correctly
You need to confirm that the desktop environment actually loaded and that your terminal can communicate with it. The environment variables tell you which session is active. The loginctl command shows you the session state and the display server in use.
Here is how to check your current desktop environment and session type from a terminal.
# Print the XDG_CURRENT_DESKTOP variable to identify the active environment
echo $XDG_CURRENT_DESKTOP
# Output will be GNOME, KDE, or a comma-separated list if mixed
# This variable tells applications which settings backend to query
# Show detailed session information including the display server type
loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type,State,Display
# Type shows wayland or x11, State shows active or closing
# This confirms the session wrapper matched your login screen selection
If the output shows GNOME but you selected Plasma, your session failed to initialize correctly. Check the journal for the specific unit that crashed. Run journalctl -xeu plasmashell.service or journalctl -xeu gnome-shell.service depending on what you intended to start. The logs will point to missing dependencies or conflicting configuration files.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and configuration drift
Installing two desktop environments introduces predictable friction. The first issue is application overlap. You will have nautilus and dolphin. You will have gnome-terminal and konsole. You will have gnome-control-center and systemsettings. They do not share preferences. Changing your default file manager in GNOME settings does not update KDE. Changing your keyboard layout in Plasma does not update GNOME. You must configure each environment separately. Accept the duplication. It is the price of isolation.
The second issue is display server mismatch. GNOME defaults to Wayland on modern Fedora releases. KDE Plasma supports both but may default to X11 on laptops with certain NVIDIA drivers or older hardware. If you log into Plasma and notice missing features like fractional scaling or clipboard sharing, check which backend loaded. Switch to the Wayland option at the login screen. If Wayland fails to start, the journal will show a Failed to start session message. Do not force X11 unless you have a specific hardware requirement. Wayland is the Fedora default for a reason.
The third issue is extension and theme conflicts. GNOME extensions run inside gnome-shell. They do nothing in Plasma. KDE Plasma widgets run inside plasmashell. They do nothing in GNOME. If you install a global theme that targets both, it may break one of them. Stick to environment-specific themes. Use gnome-tweaks for GNOME. Use systemsettings for KDE. Keep the toolchains separate.
Here is what the error looks like when a session fails to start due to a missing dependency or corrupted config.
Failed to start session: org.freedesktop.DBus.Error.ServiceUnknown
The name org.gnome.SessionManager was not provided by any .service files
This message means the session manager could not find the required desktop files. It usually happens after a partial dnf remove or a manual deletion of /usr/share/wayland-sessions/. Restore the group with sudo dnf group install "GNOME Desktop" --refresh. The --refresh flag forces metadata updates and ensures you get the latest package versions.
Run journalctl -xe first. Read the actual error before guessing.
Which desktop fits your workflow
Use GNOME when you want a consistent, keyboard-driven workflow with minimal configuration overhead. Use KDE Plasma when you need granular control over window management, desktop widgets, and system behavior. Use the default GNOME spin when you are running a standard workstation and rarely touch the terminal for desktop tweaks. Use the KDE Plasma spin when you prefer a traditional taskbar layout and want to customize every pixel without installing third-party tools. Stay on the environment you installed first if you only deviate from the defaults occasionally. Switch only when your daily tasks require features the other stack provides.