Linux GUI

Basics

A loosely-structured hierarchy of components ultimately all work together to provide you with a graphical experience. From the "ground up" they are:

• A display server protocol. X11, Wayland. (See: X Windowing, Wayland. Also Quartz on MacOS.)
  
  
• A display server is a service that provides an interface for applications to present a simple graphical interface to the user. (There's basically only one display server left that implements the X11 protocol, the one from X.Org. There are several display servers that implement the Wayland protocol, e.g. Weston, Mutter, KWin, Sway. Also, on Wayland the tasks of display server, window manager, and compositor are often done by the same program.) X has a model of dumb clients, with each framebuffer containing data for a whole display. Wayland has a model of smart clients, with each buffer representing an individual window.
  
  
• A window manager is a service that works with the display server to present applications via one or more windows. These come in several flavors:
  
  
  • A stacking window manager is the traditional concept, where one window is "on top" and all the others are layered behind. (See: Xfwm, Openbox, Fluxbox)
    
    
  • A tiling window manager presents windows to the user in a way that they're never overlapping. (See: awesome, bspwm, xmonad).
    
    
  • A dynamic window manager can switch between tiling and stacking. (See: dwm, i3, sawfish)
    
    
  • A compositing window manager (or compositor) is similar to a stacking window manager, except that it provides each application its own off-screen buffer first, and then composites those buffers together on screen. This provides additional features like alpha-blended windows, animations, desktop wall/cube, etc. (See: Compiz, Mutter)
    
    
• A widget toolkit is an code library applications use to draw widgets (menus, buttons, etc.) onto the windows provided by the window manager. (See: Qt, GTK)
  
  
• A graphical shell is an application that provides the basics concepts like login screen, task bar, system tray, etc. (See: GNOME shell, KDE Plasma)
  
  
• A desktop environment is the coordination of all these layers, plus any number of additional applications, into a single user experience. (See: GNOME, KDE)
  
  
• A Linux distribution will package a desktop environment with more applications, plus an installer, software repository, etc. to form a complete operating system.
  
  

A window manager handles the placement, movement and geometry of windows. It also handles titlebars, borders and other decorations.

A compositor is responsible for transparency of windows and other fancy effects such as fade in/out, preventing screen tearing, animations, more.

A desktop environment is a set of tools, integrated together to give you a comfortable experience. It consists of window manager, compositor, status bar, settings manager, polkit agent, more.

In many cases your window manager and compositor are the same. There are three types of window managers:

• Tiling - these are less common, but their distinguishing feature is that they don't allow windows to overlap. They arrange windows on the screen so that you can always see the entire contents of all windows.
  
  
• Stacking - this is a bit more typical. Windows used a stacking WM until Windows Vista. It allows windows to overlap, but when it draws the screen it uses the painter's algorithm to come up with the final image. That means that it actually overwrites the image of each window in memory as it stacks the windows. This means the window manager needs to ask each program for its contents to redraw a window, if for example you move a window out of the way of another.
  
  
• Compositing - the key difference between stacking and compositing is that compositing window managers hold the contents of all windows in memory and create a final, composite image by manipulating all of them. This allows for effects like "peeking" windows or Mac OS expose-like functionality. It also allows for "fancy" effects like distorting windows.
  
  

Kwin (used by Plasma), xfwm (used by Xfce), mutter (used by GNOME), more ... are compositing window managers, so there is no driving need for a separate compositor. You can still disable the compositing functionality of some (xfwm and kwin, not mutter) and add a separate compositor like picom.

Also note that this all applies to the X window system. On Wayland, you must always have a compositor built into your window manager and they generally just call them "Wayland compositors" rather than window managers.

Desktop Environments (DEs)

• GNOME (originally "GNU Network Object Model Environment"):
  
  GNOME is based on the GTK toolkit (originally "GIMP ToolKit").
  
  There was a big transition from GTK 2 to GTK 3, and apparently it affected UI. Some desktops (Unity, Cinnamon, MATE ?) stayed with a GTK-2-type UI while others (GNOME) went to a GTK-3-type UI ? Some time after 2020, there will be a GTK 4. Only the LXDE desktop still uses GTK 2 underneath ?
  
  "gnome-shell --version"
  
  From discussion on reddit 8/2020:

  
  ... there is no stable API for extensions to use.
  
  Instead, extensions that do major changes are actually doing monkey-patching, with fairly predictable impacts if there are either issues with the extensions ... Or if the code changes.
  
  And because there is no stable extensions API, there's really no good way for the developers to even know when a change is going to break an extension. The tools simply don't exist to tell them.
  
  And the more invasive the extension is, the more likely it is to break in a minor release.
  
  And sadly, the only real way to fix the problem would be to create a stable extension API, but that would break every single extension currently in existence, it would limit what extensions can do to what there is an API to do, and it would take an extremely large amount of time and energy.
  
  And the gnome-shell developers don't currently have that spare time and energy for the project.
  
  ...
  
  GNOME constantly removes important features (indicator icons, desktop icons, ...). Any time someone complains about that, the answer is always "just use an extension".
  
  GNOME constantly breaks extensions. Any time someone complains about that, the answer is always "well you shouldn't have been using extensions".
  
  It's actually maddening.

  
  This helps to explain why I don't like GNOME: Joey Sneddon article. I want system theming and extensions and preferences.
  
  Wikipedia's "GNOME"
  Egidio Docile's "Introduction to the dconf configuration system"
  Joshua Strobl's "Building an Alternative Ecosystem"
  
  
  
  
• KDE (originally "Kool Desktop Environment"):
  
  KDE is a Qt-based framework, large set of applications (KDE Gear), and the Plasma desktop. "KDE Frameworks are 83 add-on libraries to Qt which provide a wide variety of commonly needed functionality ...". "KDE Gear is a set of apps and other software created and maintained by the KDE Community."
  
  For the very latest KDE, updated constantly, use the KDE Neon distro.
  For KDE with the latest kernel, more stable, use the Kubuntu distro.
  "plasmashell --version"
  liquidshell is an alternative to plasmashell.
  
  Paraphrased from Michael Tunnell 9/2019 in Linux Lad's podcast "Season 3 - Episode 1: KDE Konundrum":

  
  KDE / Plasma has a much better internal architecture / modularity than GNOME. For example, GNOME (shell) runs on a single thread, so with Wayland, if that dies, you have to reboot. Another example: it's very easy to just replace a settings module or something in KDE without disturbing the rest of the modules.
  
  GNOME has a more polished UI than KDE, although the latest Plasma desktop is getting there. KDE actually gives too much choice sometimes, and you may have to dig very deep to find the setting you want.
  
  KDE Connect (also somewhat ported to make Zorin Connect) is awesome. Through Wi-Fi, it connects smartphone and computer and provides all kinds of clipboard and file and UI sharing.
  
  [To change to the GNOME workflow:]
  Replace every panel with Latte dock (in panel-mode).

  
  Akonadi is a PIM/data framework for maintaining/accessing shared data such as address book, calendar, mail, etc. "akonadictl status" KDE PIM
  
  Make KDE dialogs the default file pickers for Flatpaks:
  Edit /etc/environment to set: GTK_USE_PORTAL=1 XDG_CURRENT_DESKTOP=KDE and install xdg-desktop-portal-gnome ?
  
  KDE developer platform
  niccolove's "Understanding KDE Plasma theming system"
  Dedoimedo's "Plasma desktop customization guide - How to for newbies"
  paju1986/PlasmaConfSaver (copy "com.pajuelo.plasmaConfSaver" folder into ~/.local/share/plasma/plasmoids/, then you can find it in Add Widgets)
  
  Re: Why do none of the major distros have KDE Plasma as default?
  from /u/Conan_Kudo on reddit 9/2022:

  
  There are two major problems with KDE Plasma today:
  
  

  • The lifecycle: KDE Plasma does not have a homogeneous release cadence and life cycle like GNOME does. KDE Frameworks are released monthly, KDE Gear and KDE Plasma are released every 4 months, but at different times. There's basically no harmony across these critical parts of the KDE Plasma stack. This is also compounded by the mess that is KDE Plasma LTS. KDE Plasma LTS only covers KDE Plasma. The Frameworks and Gear are not included. This is a nightmare to collect and release. Actually, Fedora doesn't even ship Plasma LTS for RHEL/CentOS users any more because it's just not viable for a good long-term experience. We upgrade KDE Plasma for RHEL/CentOS users regularly now. For comparison, everything for GNOME is released together, and GNOME releases every six months. This consistency also makes it easier for Enterprise Linux distributions (Red Hat Enterprise Linux [RHEL] and SUSE Linux Enterprise [SLE]) to consider upgrading GNOME on a regular basis (SLE does it every two years, for example).
    
    
  • The sprawl: The KDE ecosystem is more than double the size of GNOME. A fully-featured KDE Plasma setup is almost 600 components.
    
    

  As someone who works to offer KDE Plasma (for Fedora), I can say it's really hard. The size of the dependency-chain for KDE Plasma blew up with the transition from KDE SC 4 to KDE Plasma 5, and keeping everything working is a challenge.
  
  Red Hat was the last Linux distribution vendor to ship KDE and support it. That ended with Red Hat Enterprise Linux 8 because they couldn't take on the workload of KDE Plasma 5 and work on everything else they're doing in the desktop. So RHEL 8 became GNOME-only. SUSE dropped KDE Plasma with SUSE Linux Enterprise 12 for similar reasons, but they'd been pushed harder into the GNOME fold by Novell acquiring Ximian and merging it into SUSE decades ago. Mandriva went belly-up in 2015, but had laid off their staff in 2010 (in the KDE 4 days). Canonical never embraced KDE technologies, as they followed using GNOME from Debian, and later developed Unity, and now switched back to GNOME.
  
  The only problem with GNOME is their people (specifically their attitude and ability to handle criticism). And when Linux companies are paying employees to work in GNOME, it's a lot easier to ignore that. That's a big part of why GNOME has never course-corrected on their attitude as a project, nor has the Foundation ensured that new folks get a friendly experience with GNOME. As long as they're funded and they're the default for all the commercially successful distributions, they really don't have to change.
  
  The KDE community is awesome to work with, but the difficulty of keeping up with their stack makes things too hard from a commercial standpoint. I personally hope that KDE Plasma 6 will be an opportunity to fix some of this mess, because some simplification here could vastly improve the commercial viability of the desktop.
  
  Source: Works on Fedora KDE as a member of the Fedora KDE SIG

  
  
  
  
  
• Cinnamon:
  
  
  
  
• MATE:
  
  
  
  
• COSMIC:
  
  System76 blog article
  
  
  
• ...:
  
  
  
  

> There are heavy desktop environments such as GNOME and KDE.
>
> And there are lightweight alternatives such as
> Xfce, LXDE and LXQT.
>
> So what are the extra features offered by GNOME /
> KDE / Cinnamon apart from eye candies and accelerated
> 3D animation effects using the GPU, that make
> users choose them?

Heavy-/lightweight categorization is not so easy, for example in memory usage Plasma and xfce only differ in about 50 MB ... less of difference than xfce and lxde. There aren't many "tests" beyond memory consumption, hardly anything on power consumption or CPU usage. So first off, best ignore voices trying to categorize DEs that simply ... it's more guesswork than anything substantial.

Then DEs have to be separated into their "shell" and their framework. What you ask about is probably the shell, how a DE looks to a user, what tools are available, how it acts, how it can be controlled.

The framework part is not something you as user really can have an influence on. You have no choice in the matter what DE frameworks an application uses, that's a decision application developers do. Framework libraries contain stuff usually not visible for users but important for applications like GNOME's dconf system or KDE's kconfig as framework for saving application config data. No matter what DE shell you have installed ... the framework libraries of other DEs will still work. Meaning ... if you use GNOME but also krita you will need some KDE framework libraries as those are how krita saves its config, loads images, displays some gui elements ...

So as user your only choice is selecting an appropriate Desktop shell for your workflow. And here are huge differences between the DEs and why some people select one of the other. Things like:

• Default applications and their depth. GNOME for example has a GNOME Boxes application that allows very simple setup of virtual machines ... as far as I know no other DE has any similar application. KDE has a full-fledged system-monitoring tool with client/server architecture for watching remote machines in ksysguard. Lots of such examples where the default apps differ vastly between the DEs. Of course you could use applications from one DE in another ... but a lot people prefer tightly-integrated solutions and not different config settings for the most basic programs for example.
  
  
• Services provided by the DEs ... things like file indexing services, clipboard manager, password manager, window management tools ... again large difference between the DEs there what is available and what it can do. Kwin's window rule system is pretty much unmatched by any other DE while GNOME's gvfs allows using of GNOME-specific virtual filesystems for pretty much any applications, even non-GNOME applications.
  
  
• Workflow. Do you prefer an activity-oriented workflow like GNOME has, a traditional workflow like Xfce or LXQt ... or rather Plasma that has elements of everything but requires you to set up everything as you want it.
  
  
• Appearance ... sorry not much I can say there as I never cared but lots of people seem to have strong preferences for specific appearances and themes so for sure a reason why people choose a specific DE.
  
  
• Configuration scope. Large differences of the configuration frontends DEs offer for non-DE stuff. Not every DE has a configuration frontend for systemd, joysticks, power management, locales ... and not every user wants their DE to control stuff unrelated to it.
  
  

I spend most of my time in several major apps (browser, IDE, feed reader) in full-screen mode, so much of the time the DE doesn't matter much to me.

These days, most desktop machines have at least 4 GB of RAM; my laptop has 16 GB. An extra 200 MB taken by one DE versus another DE just doesn't matter much to most people.

You can turn off some DE behavior to make it "lighter": animations, transparency, search indexing. On KDE, Settings / Display and Monitor / Compositor and turn it off.

> GNOME vs KDE ?

Both DEs are technically accomplished and sufficiently reliable and performant (outside of some corner cases).

GNOME's philosophical guideline is minimalism: the DE should do nothing to get between the user and their work.

KDE believes that in so far as practical the user should have control of every element of the DE.

...

GNOME positives:

The apps are minimalist and free of clutter. It's primarily keyboard-driven (only reason I don't use other DE's). The extensions are a massive plus, (why use Cinnamon or Budgie when you have dash to panel?)

GNOME negatives:

Lacks customization capabilities although the customization is there through a workaround. Heavy RAM usage (I don't care that much about it but it's there), certain versions are not consistent and install different packages (Arch is relatively minimal, Debian installs random extras like xterm from xfce. Why does it install these extra programs? It messes up the app menu).

GNOME isn't perfect but in my experience every other DE is a mess. KDE is a mess it's confusing, lack intuition, and can be broken if you misadjust the wrong settings. I added a binary clock to the panel and could never remove it. Then I accidentally made some mistakes and couldn't interact with the guy any more. I lost interest.

...

KDE has lots of customization ootb, but that's all you're gonna get, you can't really extend it.

...

I'm much more a GNOME guy mainly because it is (ootb) more keyboard-driven and simplistic (in good way). I tried many times using Plasma, at least for a matter of trying new things, but I always came back to GNOME. (Actually, now I'm using Cinnamon). I'm not a Plasma hater at all, but for my taste it feels so bloated in many aspects ...

...

Every time I try to use Plasma I feel like I'm meant to use the desktop. While with GNOME I don't have to think about GNOME and can just do what I want.

Plasma tends to tout features like features are inherently good. But who cares if there's split panes in a file manager when I have a file manager and half-tiling in my window manager? Way faster and doesn't waste space in a toolbar.

...

I personally dislike KDE because I find it buggy and over-complicated with the settings and configuration. I realize this is what many people like about it but I enjoy GNOME because it works well enough without configuring too much so I can just get work done.

...

Plasma is great and i love its feature-set. But it constantly feels rough around the edges. There's always some small graphical glitches, things aren't where they should be, Settings dialogs don't work or things like that. Controls outside the window borders are also a thing.

GNOME never fails me. I personally think Adwaita is one of the best themes there is, customization is somewhat there, but most of all, it's consistent and just works. I can use Extensions for the few things I'm missing (Tray icons). It's sometimes a bit boring and certainly less "flashy" than KDE, but it's solid as a rock.

...

I really like a lot of GNOME. Their Activities Overview full-screen dashboard is really nice and I love how it works with their dynamic virtual desktops system. Their System Settings app is very approachable and comprehensible, and I like their "single point of entry" idea. Their documentation is top-notch. Overall the environment is very attractive.

Ultimately I use Plasma because I want more from my machine than GNOME can provide out of the box. I want desktop icons and I want a dock. I want quarter-tiling and fractional scaling. I want the search to index all my files in arbitrary locations rather than just a few, and the ability to use the global search to launch web shortcuts and execute arbitrary commands. I want all my apps to use the same visual theming rather than visually reflecting the implementation details of which programming language and UI toolkit they were written in. And so on.

Adding extensions for those things always made my GNOME shell session crashy and laggy and generally unstable and this was frustrating. So I use Plasma because it lets me have all of those things without having to trade off system stability and spend a day tweaking stuff to download and configure them.

...

I actually think GNOME has the better, more intuitive way of customizing things. Having a single "standard" desktop experience with the ability to add extensions on top of it was probably the best idea the GNOME team has ever had. It has amazing UX design and, in my eyes, is the most beautiful desktop environment by a long shot. The documentation provided by GNOME to its users is unparalleled in how easily accessible and understandable it is. It's a great choice.

But alas, I prefer Plasma. On my poor little Intel integrated graphics processor, GNOME consistently and very visibly lags/stutters in places where Plasma pretty much never does. Using Wayland helps, but it's definitely more of a treatment than a cure. I said that GNOME was the most beautiful desktop and that's true ... until you open up something that isn't made specifically for GNOME. Plasma has excellent integration with applications of all kinds, and even when it doesn't it still manages to look good. I can have a KDE app, a Qt app, a GTK app, a GNOME app, an Electron app, a video game, a Wine program, a Java Swing app, a poorly-tested snap application and so on all opened side by side and they all look great next to each other.

...

In both Windows and Linux distros with MATE / Cinnamon / KDE I make shortcuts on the desktop or on taskbar to the most-often-used programs to find and open them quickly.

Not only that I like to make Symlink shortcuts on the desktop to other folders and files that I need often to put something in or to edit.

I didn't know how to do this with GNOME 3 or if it's even possible since desktop icons are not allowed.

There was another problem with some action missing from the power menu, sleep, hibernate, whatever, I don't remember, I had to Google it and found out that I should've known to press some keyboard letter to see it.

I hate this kind of things, I don't like hidden things.

For me KDE Plasma is just like Windows, but even better in some areas.

I like that I have desktop icons or whatever I want to put on the desktop.

I like that I have multiple start menu choices.

I like Dolphin very much, this is definitely the best file manager ever.

I like KDE Connect.

I like the Desktop integration for browsers.

I like that KDE is very fast and snappy.

I like that KDE is very customizable.

What I don't like about KDE is that the DE updates take forever.

On Kubuntu 20.04 is still not possible to update KDE to latest version.

And I don't like that there's no firewall and no privacy controls to control access to webcam, mic, location.

But Plasma is improving very fast, I'm sure these will come sooner than later.

...

The advantage of GNOME is slicker look, less bloat and very hard to find a defect.

KDE is bug-riddled; I could find a new defect every minute. But it gives way more functionality without hacks (the extensions to GNOME, pardon me, degrade the slick experience a lot). Also it doesn't look bad with non-KDE apps while KDE apps look horrible in GNOME. I actually very much love the kdewallet in the end as I can redirect password even to command line not just ssh and many apps make use of it. Everything is locked until user logs in which is great. Some "k" apps are fascinating including Krita, Kata, DigiKam but also search (I can't care less it takes 3 GB of RAM - I am getting content search results in milliseconds). The search doesn't cover settings properly, here GNOME shines with unparalled search of even your setting values. But I prefer file search. I strongly require jump lists in taskbar; for that reason I even switched to K office. Right click on taskbar or desktop in GNOME gives very little. KDE has graphics glitches that is the main issue as other defects are rather minor.

In the end I am still with KDE as I hope a historical big fix season will come soon.

On *buntu systems, apparently you can switch DEs (without re-installing) by installing the "tasksel" utility and then doing "tasksel install ubuntu-desktop" or "tasksel install gnome-session" or such.

On Fedora, "dnf grouplist -v" to see available DE's, "sudo dnf install @SOMEDE" to install one, "sudo dnf install switchdesk switchdesk-gui" to install switcher, then run Desktop Switcher application and select a DE.

From reddit:

If you just want to learn, go for it but be prepared for something going wrong.

If you genuinely dislike DE A and want to change because you must, then just reinstall same distro with DE B. Safer and probably quicker option.

...

Make sure to set up Timeshift before you begin tinkering. It lets you set up savepoints. If things go wrong, you can restore a previous savepoint.

...

If you add DE B without removing DE A you'll be fine, some manual intervention might be needed like manually switching greeter, default apps.

...

It's not unsafe, but it's more trouble than its worth and very hard to reverse/untangle.

...

As others have said, it can be really frustrating if something goes wrong. I recently played around with having multiple DEs installed and there were a lot of tiny issues. It wasn't anything too terrible to deal with, but I'm pretty familiar with how to fix stuff on Linux. If you're new to it, it could get really frustrating if something goes wrong

...

It can be cumbersome when it comes to DEs that use different toolkits (GTK and Qt primarily). A simple migration from one GTK-based DE to another GTK-based DE should be easy for example. Some manual intervention involved but not much. If you want to switch between GTK-based and Qt-based, a reinstall is recommended for sure. [I wonder about switching between GTK2-based and GTK3-based.]

In general, to switch from DE A to DE B: install packages for B, reboot (coming up into B), then remove packages for A, reboot, hope all is well.

In general, if you plan to switch DEs, maybe use Debian or Arch, which are closer to server distros, and tend to have a cleaner separation between base and DE.

To configure Qt5 (KDE) apps while using some DE other than KDE Plasma desktop, use "qt5ct" with "QT_QPA_PLATFORM=qt5ct" environment variable set.

From a DistroWatch article: Some desktops use 3-D features (Cinnamon, GNOME, Unity), others are 2-D desktops (KDE Plasma, Xfce, LXQt). You can turn off visual effects or other features to try to gain speed.

Vivek Gite's "How to install and edit desktop files on Linux"
Codrut's "Edit linux application shortcuts"

community.linuxmint.com's "How to Install and Manage Multiple Desktop Environments Using GUI"
How-To Geek's "How to Install and Use Another Desktop Environment on Linux"
StackExchange's "Why does installing different desktop environments break things?"
In Mint, open Software Manager app and search for "desktop". A bit confusing, but they're there.
One way to use multiple DE's on one distro: use a different user for each DE ?

Or maybe create a USB Live drive for the new DE and try it there for a while, before messing with your system on disk.

From someone on reddit:

> is it possible to just install a couple different desktop
> environments and switch between them when I feel like it ?

You can install most all of the *-desktop packages and select what desktop to use at the Login screen Its not that hard.

The Login manager screen has some icon of menu of all the DE's and WMs installed on the system, the user just picks one before they click the Login button.

HOWEVER ...

The icons and applications are often not very separated, and the names can be confusing because they are all mixed together.

Example, With the IDIOTIC naming scheme common these days of using 'common' terms for program names, you may have 4 'terminal' icons each called terminal, and each calling a different terminal program. KDE is a bit more clear in its menus, but some other DEs can be a real bother. it is possible to hide specific programs/icons in specific DEs but it can be annoying to tweak them all.

So in short, you can:

sudo apt install kubuntu-desktop xubuntu-desktop lubuntu-desktop budgie-desktop   

then log out, (you may need to restart the login manager) (or be lazy and reboot)

Select the correct desktop to try, log in, enjoy.

Some things to watch out for: redundant programs, poorly named programs (gee 4 icons called 'settings' how nice), Login manager might get changed (easy to change back), disk space used up, default applications might get changed also. Been running this kind of Franken-Desktop setup for ages.

I tend to go on a 'testing spree' of the other desktops, before i do a clean install, then when installing i pick what DE to try out for a while, until i get bored and do it all again.

Make your own DE

Good learning experience: Paste together your own DE.

Install a distro that has just a window manager (maybe Arch with Openbox). Then add a dock, a launcher, system tray, start menu, network manager, etc.

John Ramsden's "Building a Custom Linux Environment With Openbox"
Miguel Sampaio da Veiga's "Install and configure Openbox"

Graphical Shells

Desktop Elements

• System Indicators: usually a sequence of icons showing things such as date/time, battery state, network state, VPN state, temperature, notifications, more.
  
  
• Taskbar (KDE) or Dash (GNOME): usually a sequence of icons showing running application icons, and maybe pinned/favorite available application icons.
  
  
• Dock: like the Taskbar, but also can contain widgets, and maybe is a movable panel ?
  
  
• Start Menu: usually a button that brings up a hierarchical menu of all available GUI applications in the system, plus some system items such as shutdown, reboot, logout.
  
  
• System Tray (most DE's) or Top Bar (GNOME): usually contains Start Menu icon, Taskbar, and System Indicators. Usually along bottom or top edge of display. Essentially a Dock, but not movable.
  
  
• Application Launcher or Runner: search utility that can be configured to show lists of recently-used files, web URLs, available applications, more. Clicking on an item opens or runs it. Rofi, dmenu, KRunner, lxqt-runner, Albert. article
  
  
• Icons: icons that reside on the desktop, each mapping to a .desktop file (maybe in $HOME/.local/share/applications) that specifies an application or script to run. There may be some special icons for Computer and Trash and Home.
  
  
• Widgets / Applets: extensions that often are more complex than just indicators. Show up as panels or indicators and usually can be configured in various ways. May appear in system tray, dock, or on desktop. Some of the standard items such as Taskbar may actually be defined as Widgets/Applets.
  
  
• Application-Switcher: usually a set of icons showing running applications, usually invoked through Alt+Tab. Once it's shown, use Alt+Tab or mouse or arrow keys to move through it and select another application to give focus to. Rofi also does this.
  
  
• Workspaces / Virtual Desktops list: a list of separate groups of running applications.
  
  
• Activities list: (KDE only) "a way to have multiple Plasma setups, each with a different set of widgets and themes." KDE's "Activities"
  
  
• Settings menus: usually right-click on empty desktop (to do display settings), on Start Menu button (to configure start menu), or on an icon (Panel Toolbox in KDE) in the system tray to configure workspaces and desktop etc.
  
  
• Heads-Up Display (HUD): in NX Desktop, Unity 7 ? Allows you to search through an application's tool menu ?
  
  
• Miscellaneous: key shortcuts, hot corners, screenshot, accessibility features, developer tools, tiling mode, wallpaper/background, screensaver, software store, default text editor, default image viewer. And content items such as icons, fonts, cursors, backgrounds, logos.
  
  

Ramin Honary's "The components of a Linux Desktop Environment"

Docks

Widgets, Applets, Desklets, Extensions

Install GNOME shell extensions

In Mint, you can use the Extensions application to install from a limited list.

More extensions: GNOME Shell extensions
Martins D. Okoi's "How to Install GNOME Shell Extensions"

To see what version of GNOME you're running: "cat /usr/share/gnome/gnome-version.xml".
The web site Download may ask for "GNOME Shell version"; maybe: "apt list | grep gnome-desktop | grep installed".


I did this on Ubuntu 20.04. Late 2021, I hear it is not working in Snap or Flatpak versions of browsers.

GNOME Shell integration Installation Guide

1. Install Firefox extension
   
   

2. 
   sudo apt install chrome-gnome-shell
   gnome-shell --version
   

   
   
   
3. Click on GNOME browser extension's icon in browser toolbar, web site will open. Search for shell extension you want, click on it. Slide switch in upper-right of web page to On. See a confirmation dialog from the browser extension. Do NOT use the download link near the bottom of the page.
   
   
4. Log out of Linux and log back in.
   
   

New method:
Linux Uprising's "Extension Manager: Search And Install GNOME Shell Extensions Without Using A Web Browser"

Also:
Linux Uprising's "Search, Install And Update GNOME Shell Extensions From The Command Line"

Default system extensions:

• Desktop Icons by rastersoft (can't be replaced)
  
  
• Ubuntu AppIndicators by didrocks (entry on web site is placeholder)
  
  
• Ubuntu Dock by didrocks (entry on web site is placeholder)
  
  

I added:

• OpenWeather by jens (easily get city coordinates by adding new location, not editing existing location)
  
  
• Hide Top Bar by tuxor1337 (very nice; definitely install this one)
  
  
• I looked at about 200 other entries, didn't find any other that was appropriate for my system, interesting to me, AND would install successfully.
  
  

pling / Gnome-look.org

Themes

Window Managers

Tiling Window Managers

Mehedi Hasan's "Best 20 Linux Window Managers"
Matt Chapman's "Window Managers for X" (old list; and click on "Others...")

From someone on reddit:

[I'm running Ubuntu GNOME 20.04]

1. Find a WM you like. (I'd recommend I3, but there's awesome, dwm, qtile, xmonad, bspwm, herbstlutwm, etc.)
2. Install it through apt (or through a PPA, usually the instructions are on the GitHub repository README.md). ["sudo apt install i3" or "sudo apt install awesome"]
3. Logout and in gdm after selecting the user, click the gear icon in the lower right corner and search for the window manager you just installed.
4. Login and play with it a little bit.
5. When you want to go back to GNOME just log out of the WM (usually there's a key-binding for that in the config file) and select GNOME in the gear icon.

Downsides of tiling WM, from someone on reddit:

Tiling WMs work fine for most people. That being said, here are some issues I have with them:

• There is upfront configuration for many Tiling WMs that I just sometimes don't have the time for.
  
  
• I do not tile anything except my terminals ... so why not just use tmux instead ? Tiling most other things is painful for me, and I just keep them in full-screen.
  
  
• You can have a keyboard-driven layout for floating Window Managers as well, so do not assume it's a tiling specific feature.
  
  
• On a desktop with a wider monitor, I don't particularly care if some screen space is wasted. It's like, "yeah whatever. I'll fix that if I want to later".
  
  
• Pseudo tiling (on openbox etc) works well. In a tiling Window manager, I find most floating modes to be a bit lacking. While in most floating window managers, pseudo tiling is pretty neat.
  
  

In i3 window manager:

Jack Wallen article
Click on network icon in lower-right corner of screen to set networking.
Command-d to select an application to launch.
Command-enter to open a Terminal window.
Command-f to go to full-screen mode.
Command-shift-q to close current application.
Command-shift-e to exit i3 and go back to login screen.

In Openbox window manager:

Install "openbox", log out, and then look for choice of window managers on login screen.
If you get into Openbox, you'll see an empty desktop (just background image).
Right-click on desktop to get a menu.
Install "obconf" to get GUI config utility.
Defaults are pretty standard key-bindings: Alt-F4 to close current application, Alt-Tab to cycle through running apps.

To add applications to menu, copy /etc/xdg/openbox/menu.xml to $HOME/.config/openbox/menu.xml and then edit $HOME/.config/openbox/menu.xml https://addy-dclxvi.github.io/post/autogenerate-openbox-menu/

I found Openbox saved about 300 MB of RAM compared to Xfce.

To get wallpaper handling: install "nitrogen" or "feh" ? Don't have "change every 5 minutes".
To get system tray: install "tint2" and add "tint2 &" to $HOME/.config/openbox/autostart ?
To get network manager: install "network-manager-applet" and add "nm-applet &" to $HOME/.config/openbox/autostart ?
To get audio volume control: install "volumeicon" and add "volumeicon &" to $HOME/.config/openbox/autostart ?

https://www.dwarmstrong.org/openbox/
https://fedoramagazine.org/openbox-fedora/

In bspwm window manager:

ArchWiki's "bspwm"
Ramces Red's "How to Install and Configure bspwm in Linux"

I didn't like bspwm. Seems to be no way to alt-tab through open windows, I guess you're supposed to traverse up and down through the binary tree. Launcher just shows all executables in PATH, I think. No system tray or Start menu icon.

sudo zypper install bspwm

mkdir ~/.config/bspwm/
mkdir ~/.config/sxhkd/

# Might not need the "packages" dir in following:
cp /usr/share/doc/packages/bspwm/examples/bspwmrc ~/.config/bspwm/
cp /usr/share/doc/packages/bspwm/examples/sxhkdrc ~/.config/sxhkd/

chmod 755 ~/.config/bspwm/bspwmrc
chmod 644 ~/.config/sxhkd/sxhkdrc

# Probably have to edit ~/.config/sxhkd/sxhkdrc to change
# terminal emulator from urxvt to something else (konsole,
# gnome-terminal, etc).

# Add a help window to show commands:
# https://my-take-on.tech/2020/07/03/some-tricks-for-sxhkd-and-bspwm/#show-a-help-menu-using-rofi
sudo zypper install rofi
# Then follow instructions in that article section.

Standard shortcuts set in sxhkdrc:
super + return == terminal emulator.
super + space == program launcher.
super + alt + q == quit bspwm.
super + shift + w == close and kill current window.
super + m == alternate between the tiled and monocle layout.
super + {t,shift+t,s,f} == set window state {tiled,pseudo-tiled,floating,full-screen}

datagubbe's "FVWM: Daily Driver Config"

Stacking Window Managers

In IceWM window manager:

IceWM Window Manager Manual

It looks like a full DE, with Start menu and system tray and ability to cycle through open windows, etc. I also had KDE installed, so all the KDE apps were available.

Shortcuts:
Alt+F4 = Close the window.
Alt+F6 = Focus to next window.
Alt+F9 = Minimize the window to taskbar.
Alt+F10 = Maximize the window.
Ctrl+Escape = Show the start menu.
Ctrl+Alt+Escape = Show the window list.
Shift+Escape = Show the system-menu of the window.
Alt+Escape = Focus to next window (down in zorder).
Alt+Tab = Switch between windows (top -> bottom).
Ctrl+Alt+Delete = displays the session dialog.
Ctrl+Alt+Space = Activate AddressBar, where a shell command can be typed.
Ctrl+Alt+d = Show the desktop.

"man budgie-wm"

X Windowing

man startx

# To see if you're running X or Wayland:
loginctl"   # to get session number, then:
loginctl show-session SESSIONNUM -p Type

# Or:
echo $XDG_SESSION_TYPE

ls /etc/X11/xinit
ls /usr/share/applications/ | sort

xrandr        # displays and resolutions
wmctrl -l     # open windows

wmctrl -d     # open workspaces/desktops

xlsclients    # X clients

Wayland

# To see if you're running X or Wayland:
loginctl      # to get session number, then:
loginctl show-session SESSIONNUM -p Type

# Or:
echo $XDG_SESSION_TYPE

wdisplays
wlr-randr
kanshi

# To add Wayland session option to KDE:
sudo apt install plasma-wayland-session

eglinfo       # (part of mesa-demos)

# Log files ?
export WAYLAND_DEBUG=1     # ?
cat /var/log/weston.log    # ?

man wlrctl

What you don't see is just about everything in Wayland goes through xWayland, which is exactly X.

So for example copy/paste between windows doesn't work with Wayland, it goes through xWayland. And about a million other things. Screenshots, and so on. Install wayland WITHOUT xwayland, and you'll see everything is broken. And the transaction counts are actually higher in Wayland than X, because there is a security model that is completely stupid.

They keep saying "this is temporary, eventually we'll remove xwayland". But every year, xwayland becomes more and more essential.

I'll repeat it: xwayland is x. So they never got rid of X, and can't. In the end they are just creating a super-complicated system, which depends on X for anything.

Wayland also has tons of problems which are swept under the rug. Take fractional scaling. Say your monitor is 3840x2160. You can easily set the resolution to 2560x1440 in X, and your performance increases, since it's less pixels to process. But in Wayland, this depends on the compositor. So say you scale it to that resolution. It's all good, right? Wrong. Each transaction now needs to be done like 2-3 times internally. Check your performance, it just tanked to ridiculous levels.

Display (Login) Managers

loginctl session-status
loginctl show-session 2 -p Service

ls /etc/X11
cat /etc/X11/default-display-manager
sudo systemctl status display-manager --full --lines 1000
systemctl cat display-manager.service
grep '/usr/s\?bin' /etc/systemd/system/display-manager.service
ls -l /etc/systemd/system/display-manager.service     # symlink to DM in use
# On openSUSE:
update-alternatives --list default-displaymanager

# GDM:
less /etc/gdm3/daemon.conf
less /etc/gdm3/custom.conf
# Login screen is the "greeter screen", and is provided by gnome-shell.
less /etc/gdm3/greeter.dconf-defaults
sudo ls /var/log/gdm3/

# SDDM:
ls /etc/sddm
ls /etc/sddm.conf.d
sudo systemctl status sddm
# Installing sddm-kcm package adds a GUI config module to Plasma Settings.

$ LightDM:
less /etc/lightdm/lightdm.conf
ls /usr/share/lightdm/lightdm.conf.d
ls /usr/share/xdg/lightdm/lightdm.conf.d
sudo less /var/log/lightdm/lightdm.log

man systemd-logind
man logind.conf

# All session choices listed in login screen:
ls /usr/share/xsessions/

Login Process

• Single desktop computer (not client/server machines for X).
• systemd is used.
• GUI login, not console/TTY or sshd login.
• X windowing is used.
• Display manager uses systemd-logind.

1. System has reached systemd graphical.target (passing through multi-user.target on the way: "systemctl cat graphical.target"), with an X session and a display (login) manager running ("systemctl cat display-manager.service").
   
   
2. User enters credentials into display manager window.
   
   
3. Display manager contacts systemd-logind (over D-Bus ?) to authenticate user. PAM is used ("ls /etc/pam.d", "man 7 pam").
   
   
4. Authentication succeeds in PAM ("ls -l $XAUTHORITY").
   
   
5. pam_systemd.so (from /etc/pam.d/common-session or /etc/pam.d/runuser-l) calls logind ?
   
   
6. Logind creates:
   a systemd user session (named "session-NNN.scope"),
   then under that a user slice (named "user@THEUSERID.service"),
   and under that a user session slice (named "session.slice").
   

   
   systemctl status "user-`id -u`.slice"
   systemctl status --user
   systemctl cat user@
   
   man org.freedesktop.login1
   man systemd-logind.service
   

   https://www.freedesktop.org/software/systemd/man/sd-login.html#
   
7. Logind runs a session manager (e.g. gnome-session).
   
   

   
   man gnome-session
   env | grep XDG
   ps -a
   

   Somewhere in here: GDM3's /etc/gdm3/Xsession is run (which does $HOME/.profile), /etc/xdg/autostart/* desktop files are run.
   
   From LXQt's "ConfigLaunch":
   "Display managers like SDDM or LightDM are looking for available sessions in files $XDG_DATA_DIRS/xsessions/*.desktop where $XDG_DATA_DIRS is set to /usr/share/ most of the time."
   
   On Pop!_OS: /usr/share/xsessions/pop.desktop contains

   Exec=env GNOME_SHELL_SESSION_MODE=pop /usr/bin/gnome-session --session=pop
   

   
   On LXQt: lxqt-session
   
   
8. Window manager is run.
   
   gnome-shell, which is compiled with libmutter.
   GNOME's "GnomeShell / Technology"
   
   On LXQt: maybe openbox ?
   On Xfce: xfwm4.
   On Budgie: budgie-wm, which is a wrapper for libmutter.
   
   
9. DE's graphical shell is run.
   
   

   
   ps -e | grep shell
   

   
   gnome-shell again.
   Or xfce4-panel.
   
   
10. DE's graphical shell loads widgets, extensions, icons, panels, etc.
    
    
11. DE's graphical shell makes desktop appear.
    
    
12. Process sd-pam is part of systemd session so that when the systemd session is closed, the PAM session will be closed.
    
    

Desktop Frameworks

• GTK: used by GNOME, Cinnamon, MATE, Budgie (until version 11), Xfce, Pantheon, Sugar, Phosh, Unity 7, LXDE desktops.
  
  
• Qt: used by KDE, DDE, UKUI, LXQt, Sailfish, Ubuntu Touch, Lumina, Unity 8, Trinity desktops.
  
  
• EFL: used by Enlightenment desktop, IoT, Budgie (starting with version 11).
  
  
• Iced: used by new COSMIC desktop.
  
  

... Qt, it's simple yet very powerful. Qt's C++ is basically a whole different language compared to "standard" C++ due to historical (imho bad in hindsight) choices, but you can write entire apps without touching it using a JS-like language called QML which is quite powerful. It also has lots of neat frameworks like Bluetooth, serial, ... which are very nice and abstract a lot of stuff away from you. The KDE frameworks are the cherry on top though, lots of functionality can be plugged in for free in your app thanks to them ...

...

Nothing's preventing you from using C++17 or 20 tools and idioms in Qt, except for signals and slots (and therefore QThread), which need to be able to cross thread boundaries as needed. You don't need to use QFile if you want to use std::filesystem. The only things that really need to be Qt are widget (or data model) related stuff that plugs right into widget rendering.

For that matter, QML can get you really far by itself with a lot less code. I still do the classic Qt thing most of the time, but QML has a lot of appeal, especially if you want to be mobile-portable.

...

You can write your backend in regular old C/C++ and just use Qt's weirdness in the UI parts of your code where you're actually using Qt. That's what I do in my app. If I wanted I could build a CLI version without any Qt dependencies that way.

...

[Isn't GTK an equally well-supported platform?] On Linux, yes. On Windows and MacOS, not much at all, and not natively (requires MingW/Cygwin).

GTK and Qt aren't much alike, really. GTK's functionality is very much a subset of Qt's.

...

Qt is more programmer-friendly too in the way it handles elements. GTK is a moshpit of code. Qt is more organized.

If you're not already used to GTK and are a beginner about to learn, Qt is the way to go.

Layers of frameworks/toolkits/libraries

[Not sure all of this is accurate.]

Designers / Builders for the toolkits:

• Glade: for GTK ?
• Qt Designer: for Qt.

Higher-level toolkits:

• GTK: Use via C and Vala languages, or something that binds through C.
  Used in the GNOME, Cinnamon, LXDE, Xfce desktop environments.
  Nitesh Kumar's "How to Create a Simple Application in Python and GTK3"
  GeeksforGeeks' "How to create GUI in C programming using GTK Toolkit"
  GNOME's "Getting Started"
  
  
• Qt: Use via C++, QML, Python languages.
  Used in the KDE, Unity, LXQt, Lumina desktop environments.
  Qt5 Cadaques - A Book about Qt5
  Mike Royal's "Qt Guide"
  
  
• Electron: write in HTML / CSS / JS on top of Node, in browser engine.
  
  
• Chromium Embedded Framework (CEF): many languages.
  
  
• Swing: Use via Java language.
  
  
• Clutter: Use via C language.
  
  
• SDL:
  
  
• Tk:
  
  
• Enlightenment Foundation Libraries (EFL):
  
  
• Iced:
  
  
• Flutter:
  
  
• Kivy: Python.
  
  
• Dear PyGui: Python.
  
  
• Dear ImGui: C++.
  
  
• Nuklear:
  
  

Wikipedia's "List of widget toolkits"
Wikipedia's "List of platform-independent GUI libraries"
Joshua Strobl's "Building an Alternative Ecosystem"

Some apps use a lower level: drawing libraries instead of toolkits:

• Cairo: Connects to X Windowing. Used by Firefox browser, through a custom fork of GTK ?
  
  
• OpenGL: Connects to Mesa. Used by Blender app, through a custom toolkit.
  
  
• Direct3D:
  
  
• Vulkan:
  
  
• WebGPU:
  
  

Next level down:

• Xlib or XCB, libraries that connect to X Windowing System.
  X does both window management and rendering.
  Clean Rinse's "The Linux Graphics Stack"
  
  
• Mesa.
  Does rendering only ?
  Wikipedia's "Mesa (computer graphics)"
  
  
• Wayland.
  Does window management only, uses Mesa for rendering ?
  Wikipedia's "Wayland (display server protocol)"
  
  
• Mir.
  Does window management only, can use X, Wayland and/or Mesa.
  Wikipedia's "Mir (software)"
  
  

Baeldung's "GUI Under Linux"
Thomas Zimmermann's "The Linux graphics stack in a nutshell"
"QT vs. GTK+" section of SoByte's "Linux terminal/graphic interface and desktop environment"
andi's "I want to talk about WebGPU"

Portals

[Not sure all of this is accurate.]

Portals are a way for containerized GUI apps (such as Snaps and Flatpaks) to safely interact with the user to do filesystem operations such as file-open and file-save.

An app inside the container has a standard API to portals, but then outside the container there is a connector process "xdg-desktop-portal" and a DE-specific portal process "xdg-desktop-portal-SOMETHING" running.
"ps -ax | grep [x]dg-desktop-portal"

There also can be processes "xdg-permission-store" and "xdg-document-portal".


From /u/chrisawl on reddit 2/2023:

> Does every Flatpak app have to use Portals if it wants to access files ?

A Flatpak app can open an in-process file chooser, but that will only have access to files inside the sandbox.

> The save-file dialog doesn't remember last directory saved-to,
> and doesn't have a "recent" feature. A major pain when, for
> example, in Firefox saving multiple images from a web page
> to a directory. You have to navigate to same directory again
> and again.

Firefox saves the last used directory, but this feature breaks when it restores a document portal path: https://bugzilla.mozilla.org/show_bug.cgi?id=1775497

xdg-desktop-portal-gnome also saves the last used directory per application, but this doesn't work when Firefox tries to do it itself. I'm not sure what the other portal impls do here. x-d-p-gtk doesn't appear to have an equivalent feature, but it may get something for free from GTK3.

The Recent list in the GTK file dialog is for recent files, not directories that files were recently saved in, so the current behavior makes sense to me.

Restoring the last used path is a separate issue. If you're using a portal impl other than x-d-p-gnome, filing a bug to request an equivalent to https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/55 would be reasonable. But again, this won't help Firefox as long as it tries to do it itself.

Alternatively, the FileChooser portal API could be extended (https://github.com/flatpak/xdg-desktop-portal/issues/886#issuecomment-1347478359) to allow Firefox to restore the path properly, but that's a much larger task.

Then I noticed that Ungoogled-Chromium browser, and Akregator RSS reader, which also are Flatpaks, do NOT have this problem. They remember last-saved-to directory properly.


Disappointed with Portals security model:

I installed the Flatpak image of Firefox browser, and thought it had a bug. I have Flatpak permissions set (through Flatseal) to not allow access to ~/Documents, yet I can save files into there.

Got response from someone on reddit:

There are two different kinds of permissions, static and dynamic ones. Static permissions are those that an app always has (as long as it is running); Flatseal is for managing those. Dynamic permissions are granted (via something called "portals") only when they are needed, and that involves a user interaction (in your case, that was when you selected the file in the file chooser).

Generally the goal is that apps should use portals as much as possible, so that the user doesn't have to manually manage permissions. Another advantage of portals is that the permissions are much more targeted; an app doesn't need read access to all of ~/Documents just to read one file from there.

But of course porting apps to portals (and implementing the necessary portals) takes time, and that's why static permissions exist.

...

[There is no way to prevent the user from writing a file to anywhere they choose. User action in a GUI dialog overrides any flatpak/flatseal permission settings.]

[The purpose of Flatpak's sandboxing is to restrict what each app can do (when not in a user-driven dialog).]

This is surprising to me, and not what I want. I want something consistent with the Linux permissions model, where you set a rule (directory permissions, for example) and that rule is enforced always. The rule is not context-dependent (e.g. CLI app can violate it but GUI app can't, or something).

I want to set my browser so it can access about 4 dirs in my home directory, and that's it, no matter how it tries to access anything else. I want to set my password manager so it can never do any network access, no matter how it tries to do so.

From someone else on reddit:

The file selection dialog is not Firefox, it's part of the desktop portal implementation, it's running directly on the host without the Flatpak sandbox. If you chose a file with the file dialog then you gave Firefox permission to read and write to the file, that's up until Firefox drops the file handle, so it's one-time access.

There's no way to do that with folders, the file selection dialog can only give access to files.

If an app by default has access to a folder then you can use an override to block it. You can also do block access globally and then enable per app, and this is what I'm doing.

> how do I set Firefox permissions to say
> "only access to these 4 dirs in my home dir, nothing else anywhere" ?

...

> By default, I seem to be able to save to ANY folder.

That's not Firefox this is the FileChooser portal from the XDG Desktop Portal implementation that is running on the host and which allows one-time access for a specific file (or creating one) and that's only if you clicked on the O.K./confirmation button. The browser by itself can only access the downloads folder.

> This seems to be the heart of the issue. I see one app, Firefox.
> You seem to see two. I don't care if an access it does is stimulated by the user,
> a timer, JS on a web page, a network transaction, whatever. I want that access
> to be restricted by the permissions I set on the Flatpak image.
>
> Flatpak seems to have invented a bifurcated permission structure, where
> accesses stimulated by user action get treated one way, and all others
> get treated another way.
>
> And even in Flatseal, when you set the sliders to "off" for
> "filesystems / all system files" and "filesystems / all user files",
> you're just affecting the non-portal accesses.
>
> And there's no way to make the permission settings apply to the portals, right ?
>
> I want confidence that my app X can NEVER access any files under folder F
> in ANY way, even if I push buttons to try to make it do that. I deliberately
> set a security policy, and I should not be able to casually violate it with
> a file-choose dialog.

From Flatpak's "Sandbox Permissions":
"In many cases, portals use a system component to implicitly ask the user for permission before granting access to a particular resource. For example, in the case of opening a file, the user's selection of a file using the file chooser dialog is interpreted as implicitly granting the application access to whatever file is chosen."

Apparently "portals" are a Freedesktop thing ("org.freedesktop.portal.*"):
Flatpak's "Portal Documentation"
mclasen's "Flatpak - a look behind the portal"

Apparently this is designed, will-not-fix behavior of portals: "Filesystem permissions lead to bypassing the sandbox and that is something people must be conscious of." response to issue 3637.

And the point of that bug report is that these permission settings are kind of useless, because any user of the app could save a new permission config file over top of the existing one.

I submitted Flatpak feature request 3977. Also filed Flatseal feature request 196.

Snap is ALSO going to adopt portals. This ruins container permission-control for me.

Someone said there is an option to do "flatpak run --no-documents-portal", but it may break some apps. Without portal dialogs, the normal file dialogs will only see locations inside the container ?

Much smaller issue: If you save a file somewhere, the app grants permission to itself to access that file, which is surprising and seems likely to create clutter and dangling grants.

If you open a portal dialog and the current folder location is something like "/run/1000/...", this means the application doesn't have permission to access the default or last-used location.

If you close applications and then try to unmount a disk, and it says "busy", check to see if the portal process(es) still have files open.
"lsof -c xdg | grep REG | grep -v -E '/usr|/var|/run|/SYSV|/memfd'"
Not sure what would happen if you kill the portal process holding the files; would it respawn automatically ?

Miscellaneous

I see claims that GNOME imposes a certain workflow, or MacOS does. But I don't understand those claims.

Is there any comparison article or quick summary of the various styles ?

How I use my computer (laptop with 15-inch display): I run several large apps, each in full-screen mode: browser, email client, password manager, IDE, feed reader, file manager. I Alt+Tab among the apps as needed. Some operations, such as clicking on a link, always switch me to the browser. Other operations, such as opening a file, may open a dedicated app: video-player, PDF viewer, image viewer. If I need to copy something from one app to another, I do copy-paste. Sometimes I run CLI commands or scripts to do things.

Is that my "workflow" ? How would it be any different in MacOS, Windows, KDE, GNOME, Xfce, tiling WM, etc ? Even in a tiling WM, I think I'd still run each app in full-screen mode.

Maybe a different workflow would be to have multiple displays and not have some apps in full-screen mode ?

Or: My typical day (I'm retired) starts with: make a "new day" entry in my journal, check for any commitments or to-do I have today, check email, read a couple of general news sites, check reddit for any responses to my posts, browse reddit for a while, then work through the RSS feeds I monitor. Use the IDE mostly as a text-editor for my web site and notes. All interspersed with real life: walk the dog, eat meals, shower, to stores, etc.

Is that my "workflow" ? How would it be any different in MacOS, Windows, KDE, GNOME, Xfce, tiling WM, etc ?


I asked people on reddit, and got more or less this response:

The workflow is the details of how you move among the apps, and the windows and tabs of the apps. Do you use mouse or keyboard ? Do you tile or stack windows ? Do you spread them across multiple displays ? How many keypresses or clicks do you have to do ?

Since I have one display and use each app full-screen, my workflow is generic and the DE/desktop doesn't matter much.


It seems to me that with an extension or macro-engine or massaging key-shortcut settings, any DE can suffice for any workflow. And now that large apps (in fact, ALL of my apps except the password manager) support tabs, much of the movement is inside apps.