Andrey Listopadov

Emacs GUI library

Tue, 11 Jul 2023 01:01:00 +0300

Lately, my Magit buffer broke once again because of something weird going on with major mode, and I couldn’t stash or commit hunks unless the point was at the beginning of the line. That once again reminded me that Emacs UI is not really a UI, all of it is mere text with a bunch of properties slapped on top. It’s easy to forget about it, and use such things like Treemacs, Customize, heck, even Org Mode, thinking that you’re interacting with UI elements (file nodes in Treemacs, text-boxes in Customize, Org Modes sub-trees and drawers). However, it is an illusion, though neatly crafted. It’s still text.

Well, what’s bad about it you might ask? We love to manipulate text, Emacs even makes it actually comfortable to do, with a lot of functions dedicated to it. And buffers are also a very fast way to manipulate even moderate amounts of text. But ask yourself, do you really want to do the same kind of thing in a different UI system, outside of Emacs? Maybe if it came with the same amount of useful functions? Well, maybe you’d want to, but I sure don’t.

I’ve made my own custom UI elements in Kakoune, making a file tree, and tag list plugins. That was before I actually started using Emacs as my main environment, and Kakoune text properties are much less sophisticated than ones of Emacs, but… It’s the same thing, really.

You programmatically spit some text into the buffer, then you parse it, find elements, walk on them, change them, and so on. Yes, text properties, markers, overlays, all of it makes it more robust in Emacs, but even though, things still break. Because Emacs still tries to interpret stiff in your buffer as text.

Because that’s what it does, it expects text! If you call forward-sexp on some Magit UI element it will try to do the right thing, even if there’s no right thing - there are no sexps in the Magit buffer. Well, maybe there are if you’re viewing diffs of your lisp code, and then yeah, the benefit of everything being text you can move on becomes obvious. Except when we’re talking about UI it’s not working more of the times than it is useful in an occasional context of that UI element.

I think you probably get where I’m going with this. And you probably don’t like it, but bear with me. And it’s an angry bear, so don’t threaten me more than he does, please.

What I’m trying to say is that Emacs, as a GUI application isn’t something that I’d be advertising to other people. You can make Emacs look beautiful, no doubt about that, Nano Emacs, DOOM, and others try very hard to make Emacs visually appealing. But it’s all too janky IMO. Nano Emacs looks great on the pictures, but resize a window and the illusion of a coherent interface breaks fast. So let’s look at different systems for inspiration:

Smalltalk

I’ve already mentioned Smalltalk in the past regarding comparison with Emacs in the GUI field. And I think it is a fair thing to do - both are dynamic systems that you can program with their respective language. Except, one is GUI oriented pretty much from the start, and the other one is Emacs.

Look at how Smalltalk looks when you fire up Pharo:

It’s a GUI system. Complete with windows, containing text editors, browsers, context-aware menus, and so on. Maybe it doesn’t look as pretty as your preferred GUI toolkit, but it’s not the main point.

Although, here’s how Smalltalk looks when you fire up GToolkit, which is written in Pharo:

Figure 1: Visualizing the current knowledge base through a Pharo snippet. Clicking on nodes opens the page to the right.

Figure 2: A page with a JavaScript snippet that is combined with a Pharo snippet to produce a visualization of dependencies defined in a Yarn file.

Figure 3: Explaining a domain object through examples and custom views.

There are much more pictures on the official web page.

The point of it is that you can build your own tools for your tasks in this toolkit, as shown in the pictures. They call it building an inspector, and GToolkit comes with a lot of inspectors for various kinds of data.

This is my favorite system so far, and it gets worse from here but I feel that we need to talk about other examples still.

Java Clojure

Why not? Clojure is another dynamic system, that you can change at runtime. While Java isn’t what comes to mind when speaking about beautiful and functional GUI, making GUI apps in Clojure is far more fun than it is in Java. Because again, you can update your UI elements on the fly.

There are some examples of apps where the UI is done in Clojure, one example is the game engine called Defold.

It looks like this:

Figure 4: I couldn’t find a non-skewed image on the official page.

As far as I understand, its Editor is made in Clojure, and UI is handled via the JavaFX toolkit.

Intellij Idea is many another example of a decent-looking GUI in Java, although your opinion may vary.

Still, JVM isn’t the greatest at UI, and somehow another language with a J in the name managed to do somewhat better.

Web

Lastly, the web is another way of building user interfaces, one that is quite popular today. Because the web works the same across a majority of operating systems, as browsers are ported to them with a lot of care. Browsers are also extremely capable of rendering all kinds of file formats, doing interactive stuff, and JavaScript frameworks are aimed at providing facilities for building UI that is highly responsive and interactive.

The web is however associated with slow, often unresponsive UI, a lot of wasted screen space, and unnecessary high CPU and memory usage. Mostly due to Electron packing lots of stuff. I think Electron wasn’t a bad idea, the execution was just poor. There are other projects that provide similar facilities like Ultralight, but I didn’t investigate further. I’m OK with the idea of building UI on web technologies, as long as we’re making a robust system that works across multiple devices and actually benefits from using the browser.

There’s also this project, which I find cool because it looks similar to GToolkit: natto.dev. Basically, you get an infinite canvas, on which you can place text editing widgets, video widgets, and other stuff. Keep this thing in mind, I find the idea of such UI interesting, and probably it will be explored more in the future.

But, let’s get back to Emacs, and I’ll try to explain why I was bragging about all these other systems.

Emacs

Emacs has a windowing system. Basically like a tiling window manager - you have a frame, you can divide it into windows, you can spawn other frames, you can divide them, and so on. But, these windows can only display basic text, among some graphical elements, like SVG graphics, or bitmaps. Needless to say, when compared to any of the systems I’ve talked about before the GUI capabilities of Emacs are quite limited.

Basically, Emacs is a glorified terminal, with ability to draw different font sizes and decent image support. Don’t make such a face, you know it’s not far from the truth. Again, this may be a bit harsh, but I believe we need to admit things in order to move forward.

Speaking of terminals, Emacs can actually run in a terminal! You can start it with emacs -nw and it will happily transform your terminal into Emacs. I mean, you no longer have a terminal, it just acts as a rendering engine for Emacs. So you basically get the same thing as GUI Emacs but worse, because now your terminal is responsible for rendering fonts, and you no longer have any image support. Well, there are terminals that support images, but come on.

And I think terminal support is one of the things that holds Emacs back. Think about it - why do you even need a terminal if you’re already using Emacs?

The common misconception is that you need a terminal version of Emacs to run it on headless environments, like servers, clouds, etc. You don’t. I work with remote servers constantly each day and I never open Emacs on the remote when I’m editing files there, I don’t even open a terminal for the SSH. Here are some basic workflows involving remote servers or just terminal tasks:

Need to ssh somewhere to edit files or run some commands?
- TRAMP got you covered.
  - You can even run async-shell-command in a TRAMP buffer and it will be run on the remote.
  - You even get to retain the entirety of your config without copying it onto the servers.
Need to run some commands in general?
- Again, You can call async-shell-command, it even will handle your input and password prompts in case there’s one;
- Or you can run compile, which doesn’t handle prompts but still is much more interactive than the raw terminal output.
Want to run some complex commands with editing convenience, or maybe even some TUIs?
- You can run eshell, and go nuts on scripting in Emacs Lisp and calling sh scripts from the Emacs shell;
- Or you can run a proper terminal emulator from within Emacs:
  - Vterm - a terminal based on libvterm C library;
  - EAT - a terminal emulator that can run in a region, in a buffer, and in Eshell, written in Emacs Lisp;
  - ansi-term, term - inbuilt terminal emulators in Emacs.

I don’t know how many times I got into a situation, where there’s a PDF documentation in one buffer, TRAMP in another, and I’m editing a remote file while referring to that documentation and staying within the comfort of Emacs. So no, with Emacs terminal itself isn’t needed in maybe 90% of situations, and terminal Emacs is just out of the question.

But hey, I too previously was a terminal enjoyer before Emacs, and it was too hard to even imagine how to even approach work without a terminal. As I’ve mentioned, I was using Kakoune, and prior to that, I was a Vim user. Now, with Emacs, I rarely open the terminal at all. There’s simply no need to, as there are more comfortable ways of interacting with the shell. And damn, even things like VSCode, which isn’t a terminal app at all, still manage to run as a server in a headless/remote/container context and provide you with all of its GUI features by acting as a client. So yeah, ditch the terminal version of Emacs, you’re ain’t gonna miss it.

Except, don’t. Use what you like, the solution I’m going to propose doesn’t require anything to be ditched at all. But before that, let’s talk XWidgets

XWidgets

When I was talking about the web, I’m sure some of you thought about XWidgets and Webkit support in Emacs. Like, here, I’m running the already mentioned natto.dev inside my Emacs right now:

So what gives? And at work, I occasionally use Portal to navigate through nested data structures while debugging Clojure code:

Figure 5: (the code isn’t from work, just a hobby project)

Again, what gives? This looks like we can have interactive GUIs in Emacs, much like in GToolkit and Pharo. However, there’s a catch. There’s always a catch, and in the case of Emacs, it’s that the XWidget UIs are foreign to Emacs.

Here, foreign means that inside that *xwidget-webkit: portal...* buffer nothing you expect to work will actually work. Remember how I mentioned that in Magit if you call forward-sexp it will try to do the right thing? Well, here it can’t do anything, because this isn’t a buffer really. It is an embedded widget that only looks like a buffer in the Emacs window, but it’s not.

There’s no point in calling forward-sexp because there’s literally no point in such a buffer. You can’t use Avy to jump to an element in such a buffer because there are no textual elements that Avy can look at.

Because of it, it is basically the same as if you’ve opened a separate web browser side by side with Emacs and used it to browse the web, or run Portal, and it would probably even work better. Unfortunately, we can’t embed something like Webkit into Emacs and hope that it will solve our UI problems. Or can we?

Emacs GUI Toolkit

So here’s my idea. I’m pretty sure it’s not new, but that’s not the point of this blog - it is merely a container for my thoughts, original or not.

What if, instead of embedding Webkit into Emacs, we turn this around? Hear me out.

When I was talking about opening a browser side by side with Emacs two seconds ago, I should have mentioned that window managers, or WMs for short, are quite good at placing windows. If you’re using some kind of a tiling manager, you know what I mean - you can leave window management to your window manager. Kakoune, for instance, does exactly that - instead of creating its own windowing system, like Vim or Emacs, it leaves it out for things like TMUX or i3 to solve. This, of course, has some problems too, but works well enough in general.

But I’m not saying that we should ditch windowing from Emacs and leave it to the WM, far from it. I would rather ditch frames from Emacs if you ask me, but that’s another topic.

Look at this as if Emacs was embedded into your window manager, which is basically how it works. You start your WM of choice¹, you launch Emacs, and as long as the Emacs window is focused, you live in Emacs. All of your shortcuts work, and all of your navigation habits are there.

So what if we expand on this idea? Instead of embedding Webkit, let’s embed Emacs in its current state as a UI widget.

What I’m thinking is, let’s take, say SDL2 (or maybe something like ImGui), and create a library of widgets for Emacs. We’ll then integrate Emacs into it as the runtime system behind it, much like in the case of Smalltalk, JavaFX+Clojure, and Web+JS, and provide a set of functions to navigate through widgets in a meaningful way. The widgets would include basic stuff, like buttons, text boxes, buffers, drawers, menus… wait, buffers?

Yes, why ditch something that works well? Like when you focus Emacs in your WM and it just works, when the buffer widget is in focus it will just work too! We can keep the redisplay code, it will just need to learn how to render into such widgets, which I’m sure is possible, as there’s a very similar feature in Emacs already, called child-frames.

With enough widgets, one will be able to build GUI, much like in GToolkit, but with Emacs Lisp, and we’ll still have all the legacy textual interface working, e.g. things like Magit don’t have to throw everything out of the window and adapt - they can continue to work. We just need to be sure to provide enough extensibility, and a way to implement custom widgets, much like Emacs allows right now with its text properties, overlays, and such. Then new plugins for the GUI toolkit will arrive, making Emacs even more extensible than before.

Now, imagine, you open Emacs and it creates a window that is basically like a desktop of your operating system. You open a window, and it’s a real window, floating on that desktop. Don’t like it? Just maximize it, the window widget will work similarly to how windows are created in Emacs right now. Except it doesn’t have to be a window displaying a buffer and nothing else - it can display other widgets, some of which are buffers.

Frames become virtual desktops, which they really are, it’s just that they’re represented as WM windows because Emacs didn’t include ways of switching them virtually (it did in the terminal mode actually). You can still open a separate “frame” with a given virtual desktop, so again, everything would work as you’d expect.

I’ve made a quick prototype that implements this. Here’s a live demo:

Your browser does not support the video tag.

And here’s Emacs running natto.dev and GToolkit pages in these child frames:

Figure 6: And there are some more windows below the screen that I can pan to

With this mode, I can create child frames, that act as small windows, and pan these around much like the natto.dev app I keep referring to. Note that when the window tries to split itself, instead it creates a new window near it, and tries to keep windows from overlapping by finding empty space nearby. Basically, this is almost like a different kind of window manager.

Though this thing doesn’t work as well as you’d imagine, if you want to try it, you can get it here.

The future of Emacs

…probably isn’t what I’m describing here. I don’t know. I’m just fantasizing, but the image of such a system I see behind my eyelids is great.

I depend on Emacs, it is my main tool for the job, this blog, my other hobbies, and other activities, so I want this system to evolve. This is just a route I think it could take. Again, maybe nothing of this makes any sense to you, but I encourage you to try out at least the GToolkit, I think it is the most interesting things I saw in the last years. Pharo can be a bit less exciting but it laid the foundation for GT, and I think that’s says something. If it wasn’t for Clojure, and maybe this blog which I do in Org-mode, and if I never used Emacs I would probably try GToolkit at some point, and maybe it would become my main tool, and I would probably look at Emacs as an inferior system. Well, at least when it comes to GUI capabilities. But I still love Emacs as it is, it fulfills my needs, and I can make it do what I want it to do, which is the main point.

This post was mostly a collection of random thoughts, hence the category, but I genuinely think that if a system like this can be created in Smalltalk or in the current state of the web, it is definitively possible in Emacs, there’s just not that much of an interest in it. Well, actually there is, as I’ve mentioned, people trying to make emacs more beautiful and appealing, but I think we should not forget about utility too, and thus if someone is to develop a GUI toolkit for Emacs they need to put a lot of thought into it:

What widgets to include;
How do you move from widget to widget in an efficient way;
What is best done with a mouse, and what should not be done with it;
What level of interactivity from Emacs Lisp we should get;
Other questions like this.

So yeah, it will take a lot of planning, prototyping, maybe some competing systems to progress on this - let’s see where Emacs will go in the upcoming 30 years. Maybe another XEmacs will happen, or it will be forced to evolve by something like Project Mage or Nyxt, or even another system, that would embrace GToolkit’s modal-less interface and infinite canvas. The advent of virtual and/or augmented reality makes an interesting infinite-canvas type of interface candidate in my opinion, so maybe we’ll stop seeing flat screens in the future, who knows?

Anyway, let me know what you think. If you have any thoughts you like to share, you can find my contacts on the About page. Hope it was an interesting read!

I know that Emacs can be your WM of choice, no need to tell me that. ↩︎

Comment via email

GNOME doesn't need to be that huge

Fri, 07 Oct 2022 02:45:00 +0300

I’ve been a GNOME Shell user for many years now - I’ve started using it pretty much since its initial release in 2011. I’m using GNU/Linux as my main operating system since 2008, and I started with Ubuntu, as many did back then, and what I liked about Ubuntu was its desktop environment, or DE for short. Back then Ubuntu was using Gnome 2, a predecessor to GNOME Shell (or Gnome 3), and it was great - very well thought out, customizable, responsible, and lightweight. However, with the release of Ubuntu 10.10, Canonical moved to their own DE, called Unity, and I found myself in a weird situation.

The Gnome project just announced GNOME Shell, but Ubuntu moved to its own solution. And both options were, well, how do I put it… buggy?

In my opinion, Unity wasn’t good up until the release of Ubuntu 12.04, and it became really good in 14.04. Well, at least that’s how I remember it. I didn’t like Unity so I continued to use Gnome 2 for several years.

GNOME Shell, on the other hand… Let’s just say that it became really good just recently with the release of GNOME 40. Up until the release of GNOME 3.28 it wasn’t really that good, there were performance issues, occasional crashes, and other problems. Combined with the tendency of breaking extensions with every release, and the overall direction Gnome developers took, it wasn’t the best option, again, in my opinion, especially when Unity was making good progress. But, Canonical decided that Unity isn’t that great, Unity8 wasn’t making good progress, and with the release of Ubuntu 17.10, they’ve moved to GNOME Shell too. However, they’ve used gnome 3.26 and it wasn’t particularly great at the time, as I’ve mentioned it.

Now, you may wonder - why I’m only talking about Ubuntu? There were, of course, other distributions that used Gnome at the time, it’s just I used Ubuntu back then so that’s what I remember personally. I’m no longer an Ubuntu user though, I’ve moved to Fedora, simply because it has a vanilla Gnome, without any stupid things put on top of it by the developers of the distribution, like extra extensions or themes. Yes, I prefer Gnome as is - default Adwaita theme, no extensions that change the UI, like docks.

But there’s still one problem that I think is somewhat serious, and it is a common problem with a lot of interfaces today. And I noticed this problem when Ubuntu changed to Gnome in the 17.10 release. You see, Unity was made to be something in between - something more modern than Gnome 2, yet not as modern as Gnome 3. When Gnome 3 was released in 2011 it was looking rather different from Gnome 2. Unity, on the other hand, kept the good things of Gnome 2, yet expanded on some usability features, like good support for the global menu and HUD. The in-app menu search in Unity was amazing, but I’m going away from the topic.

What’s common between most modern interfaces as of today? They’re all big. And so was Gnome, already in the year 2011 going way ahead of its time.

Mobile-oriented UI

With the increased popularity of mobile devices, there also was the rise of mobile-oriented designs. Web pages now have a dedicated mobile-friendly mode, where all elements are bigger, so it is more comfortable to navigate with a bare finger, which provides far lower precision than a mouse pointer. Mobile apps use similar designs to web pages, even to the extent that some mobile apps are made with web technologies, and some web pages can be installed as an app.

A tablet is another quite popular device type, quite similar to a smartphone but bigger and more aimed at surfing the web. However, even though it usually has a bigger screen, it is still used with fingers as the main input device, so the UI elements are still big so users could reliably navigate them.

Desktops, however, don’t suffer from this, as they have a touchpad/trackpoint/trackball/mouse to control the pointer with great precision, and rarely have a touch screen, though the latter became more popular lately. But the popularity of mobile devices impacted the desktop UI guidelines as well. The first victims were desktop versions of the mobile-first web pages - they were either just stretched-up mobile versions or desktop variants that were stylized after their mobile versions. And it started to creep into the desktop UI itself. And Gnome and macOS are affected by it the most.

If you’re a Mac user, you know that visually macOS gets closer and closer to the iPad OS with each release. Perhaps that’s because they want to unify the operating systems, and make the iPad a fully featured portable computer at some point, similar to Microsoft Surface. Maybe, it’s just my guess - I’m not an Apple user and won’t likely be one. But what this means is that UI elements are getting bigger and more spaced out, in order to be usable on both desktop and portable devices with touch screens. There’s a great post by Andrew Denty, which has a lot of images, comparing Catalina and Big Sur versions of macOS. Here’s one of the images from that post:

Figure 1: macOS Catalina on the left, Big Sur on the right

If you look at the window headerbar, you’ll notice that it is almost twice as big, as it was before. Well, not twice, but about ~1.4x bigger - the old one is 76px tall, and the new one is 106px:

Yet the close, minimize and maximize buttons size remains the same. Other elements also have bigger padding, making the UI more spacy. I guess it is considered beautiful, but I also think that this is a waste of screen space. Macs are unlikely to get touch screens any time soon, and even if they are, the increased height of the headerbar won’t make a difference for the user, who’s trying to touch the minimize button right next to the close button. So I don’t think it was a change needed to make macOS closer to having the touch-ready interface, but a pure stylistic one.

But, well, the post title was about Gnome, and here we are, talking about macOS - why? Well, because Gnome takes a lot of inspiration from macOS, as far as I can see, at least. See for yourself:

Figure 2: macOS Finder and Gnome File Manager

Yeah, yeah, I know, a Mac user will say that it’s not even close, but the inspiration is pretty clear to me. Nikitonsky even used Gnome’s settings app screenshot as a joke after a long thread on the redesign of the settings window in the macOS Ventura beta version:

Figure 3: @nikitonsky tweet

Well, enough with the comparison to macOS, let’s get back to the main topic.

Mobile-oriented desktop UI?..

Yeah, you’ve read that right - Gnome wants to be on mobile phones and on the desktop at the same time. Their UI is designed with this idea in mind. A lot of apps change layout when you resize the window to be more like a screen of the phone:

Your browser does not support the video tag.

This is a nice touch indeed, and I can appreciate the effort, especially since there are ways to run Gnome on mobile phones today. Alternatives are always good and given the sad state of Android as an operating system, I’m all for full-blown Linux on mobile devices, with nice-looking native apps. And while this is cool and all, here’s a big problem:

Gnome interface elements are just way too big on the desktop.

Here’s a screenshot of the Gnome desktop on a Full HD display:

And here’s a similar screenshot but on a 2K display:

Just by visual comparison, you can see how much more space the file manager window is using on the first screenshot. Note, however, that both screenshots have file manager windows of the very same size, e.g. there’s no interface scaling. If you have a 1920×1080 display, try opening both screenshots in full screen, to see how the UI scale changes with the resolution. I, unfortunately, don’t have two displays with the same diagonal size but different resolutions, but here’s how it looks on my two laptops, from which I’ve taken the screenshots.

Edit: After getting a few comments on the fact that comparison screenshots don’t show anything useful, as the file manager windows have the same pixel size, I understood that I was not quite exact on what I wanted people to see. The problem in my explanation was with the fact that while windows do have the same size, the text size was supposed to be different but I forgot to enable it. Sorry for the confusion, and thanks for pointing this out. I’ve enabled font scaling and re-made the screenshots, so I hope that now this will illustrate my point a bit better.

Here’s a screenshot of a display with a resolution of 1920×1200:

Figure 4: UI scale: 100%, display resolution: 1920×1200, font scale: 1x

This is how I see things on my work laptop, which has no UI or font scaling

Now the same image, but I’ve downscaled 2560×1600 to 1920×1200 and upscaled fonts to 1.33x. This way the images will have the same size, but you’ll see the difference in the UI element sizes:

Figure 5: UI scale: 75%, display resolution: 2560×1600, font scale: 1.33x

You can toggle between these screenshots to see the difference in UI scale. I, naturally, see it on screen, given that I use the latter setup on my smaller laptop, and the first screenshot represents the setup on my work laptop. And I indeed had to adjust the size of the file manager window so their geometry matched, however, note that the text size is the same¹ on both screenshots:

Figure 6: UI elements are scaled down, yet the text is the same size

I understand that this was not very obvious to see from the screenshots I provided earlier, that’s why I’ve included laptop photos that should have demonstrated this idea. Hopefully, these screenshots better illustrate my point.

The first one has a 15-inch Full HD display, the second one has a 13-inch 2K display:

Now, let’s set the screen scale on the 13-inch laptop to 125% and compare:

It may seem that apps don’t have the same size, but that’s due to the fact that the screens have different heights, and actually, 125% scaling matches how the screen would look if I had a 2k 15-inch display, instead of a 13-inch one. Here’s a better illustration:

I’ve used my GIMP skills to increase the height of the second display to match the height of the first display. You can see that the file manager windows are indeed (almost) the same size. Well, I guess I could just add a screenshot with the system scale set to 125% but the post already has way too many images, so if you want to compare them, see the footnotes section ²^,³^,⁴.

So what do I want you to take away from all of this?

I’m using the laptop on the left for 9 hours a day because it’s my work laptop. And each day I do I feel that the interface could have been 25% smaller. Notably, I felt this way even before I got myself a laptop with a higher resolution - and when I did I realized that Gnome works perfectly with this kind of pixel density.

I’m using the right laptop right before and after work. This is basically my hobby machine - I write this blog on it, and I code all my side projects on this very screen. And every time I use Gnome apps on this screen they feel right at home. I don’t have the best eyesight, mind you, so small elements should be problematic for me, but with this level of scale, they simply are not small - they’re normal.

So my takeaway here is that Gnome can safely reduce all their UI element sizes by 25% and it will still work great! Like, seriously, I even used ~/.config/monitors.xml to set the UI scale to 0.75 under the Wayland session, which looks amazing⁵ on my 1920×1080 display UI-wise. The text is a bit too small for my liking, but this can be fixed by scaling fonts up, the main thing I wanted from this is to make UI elements take less space. All UI elements such as buttons, menus, headerbars, panels, e.t.c. are perfectly usable with this scale on a regular Full HD display. The same can be done under XOrg with xrandr --output <display> --scale1.25x1.25.

On a side note, I once owned a GPD Pocket, the first revision, and it had a 7-inch screen with a 1920×1200 resolution. I’ve used Gnome on it, and funnily enough, upon installation Gnome detected that the screen is small, and automatically set the interface scale to 200%. Fractional scaling is still an experimental option, so I guess it was rounded to the next non-fractional scale available. Using it like this was not possible at all, because nothing was able to fit on the screen. I don’t have the device anymore, but I can set the scale to 200% on my work laptop and add it via GIMP to an old photo I’ve taken in 2018:

Figure 7: A mockup of how Gnome looked on GPD Pocket with scaling set to 200%

Setting the scaling to back 100% made the device usable but the text was too small. So I’ve turned font scaling only, and could use Gnome on this tiny screen without any hiccups - because all UI elements were perfectly usable in their unscaled form. GPD Pocket also has a touch screen, and even the it wasn’t affected by scale change - all elements still could have been pressed reliably with ease. I hope you can now trust me that the Gnome UI elements can be smaller without impacting usability because I’ve used Gnome on a large variety of screen sizes and resolutions.

Big for the sake of being big (or just different?)

There’s another thing I’d like to mention. Gnome is quite different from other desktop environments available for GNU/Linux. There are a lot of different DEs, of course, but the most common ones to pop up are KDE Plasma, XFCE4, MATE, and Cinnamon. All these DEs are not “big” in terms of their UI elements. KDE is more Windows-like, and Xfce and Mate are more Gnome2-like (well, Mate is a continuation of Gnome2). While Xfce and Mate are more of an old-school type of DEs, which are still mostly using UI guidelines from that era of Gnome2 but build on top of modern GTK, KDE is not. KDE aims at being modern UI, without being big, and somehow that’s possible too!

I’ve used KDE Plasma 5 for two whole years from 2017 to 2019 if I remember correctly. Even though I always was a Gnome user before that, I enjoyed my time with KDE, after I got past the initial setup. KDE, ships with a ton of settings, unlike Gnome, and for some reason, the KDE dev team decided to turn most of them on. It was a major barrier for me because I want my desktop to be as simple as possible, not as noisy as possible. So I had to turn off all these jumping cursor animations, loading circles, e.t.c. speed up window animations one step up, and so on. After that KDE felt like a big improvement over what I’ve had in other Gnome2-like desktops.

Figure 8: Official KDE Plasma 5.25 screenshot

While I liked KDE, I’m just more familiar with Gnome, so I’ve returned to it after some time, but KDE was what made me start thinking about smaller interface elements again. I also wanted Wayland, and KDE didn’t have great support for it back then, while Gnome kinda did.

But what’s interesting, is that KDE Plasma also can be used on mobile phones, yet they don’t use mobile UI on desktop, unlike Gnome. I’m not sure if Plasma mobile ships with completely different apps or reuses apps from the desktop, but as far as I can tell, all apps that are built with the Kirigami framework can work as both desktop and mobile apps, similarly to Gnome. So it can be done, even without using a big UI on a desktop. Gnome just didn’t want to do that, unfortunately.

I’ll admit, there are other desktop environments with big UI elements, it’s just the fact that Gnome is one of the most used desktop environments in the Linux ecosystem. Gnome is used by default by two major out-of-the-box distributions - Fedora and Ubuntu. It is used by default in Pop_OS!, Tails, Debian, CentOS, and RHEL, and even Oracle’s Solaris switched to it in version 11.4. This is why I think that there should be put a bit more thought on the UI guidelines, as all these distributions are not for the mobile market.

It’s getting better

Though I don’t like decisions that were made in the past by the Gnome developers, I must admit - Gnome is getting better with every release. Gnome 40 introduced a lot of tweaks to the UI, making workspaces horizontal by default for example, and changing the overview screen to better utilize space because of it. The dark mode is another new addition, and it is made good, though it’s not automatic, you need to use an extension for that, but it’s fine. What I’m saying is that the project is lively and ever-changing - maybe we’ll get a more desktop-oriented design in the future.

I’ve mentioned that I prefer not to use extensions, but in actuality, I use two extensions - maximize-to-empty-workspace and Night Theme Switcher. Because of the first one, I’ve adopted the workflow, that I think the Gnome team envisioned - one maximized window per workspace. Thus the big UI elements are not that of a problem, for me, at least, given that most of the screen is used by the maximized app, and I usually don’t stack multiple windows on one workspace.

Even though, I think Gnome shouldn’t use these huge UI elements, or at least should provide a variant of the default theme that has 20-25% smaller window-related elements. If this were done, I could use fractional scaling on my 2k laptop display, making text slightly bigger, while still having more usable space on my other Full HD laptop. But we’ll see, I guess.

Thanks for reading, and let’s hope that Gnome will become even better in the future!

There is a small rounding error after upscaling fonts to 1.333333, so the text sizes are not exactly same, but very close. ↩︎
Gnome file manager at 1920×1080 with a scale of 100% ↩︎
Gnome file manager at 2560×1600 with a scale of 100% ↩︎
Gnome file manager at 2560×1600 with a scale of 125% ↩︎
Gnome file manager at 1920×1080 with a scale of 75% (resolution was artificially increased by scale settings in ~/.config/monitors.xml) ↩︎