Pop_OS 18.04: the state of the art in GNU/Linux on desktop | Hacker News Reader

Pop_OS 18.04: the state of the art in GNU/Linux on desktop

ar.al

83 pointsjgalvez106 comments

> Having multiple monitors doesn’t remove the need to know which app you’re in or to perform actions specific to that app. Just like the Activities button, the App Menu resides at a known location on your primary monitor and serves a crucial role as a landmark.

I have to strongly disagree on this one. Having my window open in my 3rd monitor - and having to go back to the 1st monitor every time I have to use a menu item - seems like a kafkaesque nightmare to me.

Indeed. MacOS used to only have the application menu bar on the primary monitor -- it was infuriating to use with large monitors or mis-matched sized screens like a laptop + external monitor. This was around 2013 or so?

> Having my window open in my 3rd monitor - and having to go back to the 1st monitor every time I have to use a menu item - seems like a kafkaesque nightmare to me.

Indeed, I had to suffer that experience on macOS at some point, and it just kills all the benefits of Fitts's law. There were glorious hacks of apps dedicated to restoring sanity by making the menubar present on all screens, until the feature went native. Nonetheless it does not detract from the fact that I find the menubar concept insanely good compared to per window menus as Windows and Linux had (although this was a configurable in KDE, the implementation was disastrous).

Menubar concept never made sense to me. If i have a window on the bottom right of the screen, why should i have to go to top left side of the screen to interact with its menu ?

This is literally the same issue with monitors but on a smaller scale.

Historically it’s from a time when mice were new and the idea was you could always just push to the top of the screen and never miss the menu (source: HCI lecturer at college) and of course screens being small having only one menu bar saved space too

As I said, this is Fitt's law[0], and it's a very valid thing that goes well, well beyond HCI.

[0]: https://en.wikipedia.org/wiki/Fitts's_law

This is because macOS uses a document-centric model, in which case the window is a document, as opposed to Windows where the window is the application. In the former case it is therefore perfectly possible for the application to be running when no document (hence no window) is opened.

MacOS is still relying on design cues from the days when all they had was a 7" monitor screen.

Additionally, it's designed for the hardware it's run on: a single screen laptop or desktop computer. Yes, it can run on multiple monitors, but's not really designed to do that. I don't think Apple has ever totally internalized the idea of multiple monitors or even big hardware (except for a brief time when we had a real Mac Pro).

It's odd that the author is an interaction designer, but goes on such a rant about keeping a feature that proved to work badly when tested on actual users. I'd say actual testing should trump whatever intuition you have about what works well.

Sure, he theorises that the reason is doesn't work for users is because it hasn't been implemented properly everywhere (which the GNOME developers also state), but "we should expend effort on getting third parties to adhere to the HIG" is a classic cop-out: "things would be better if we would just do them better".

Sure, if you can show that the reason third parties do not adhere to the HIG is lack of effort from the team, and you have reason to believe that there is a way to increase the amount of effort spent on that other than saying "just do it", then by all means, go for it. But if that's not the case, the only valid conclusion is that the desired state might not be possible, and removing such a feature is the only proper course of action.

Also even if every app on this planet supported it properly, you should still listen to the users. If they feel like it's wrong that the menu is disconnected from the applications main window, you can come along and go "but most apps have multiple windows and the actions in the menu are application specific, not window specific" and feel really smart about it, or acknowledge that this might be an artificial rule that while technically correct still leads to inferior UX. Because our simple dummy brains just get more confused by the fact that this menu seems entirely disconnected from the application than they would by the fact that the menu is arbitrarily fused to a random window of the application. Really most of the time it's not even that random because many apps have just one main window while the others are tool boxes, settings windows or other dialogs you only open occasionally for a short moment.

Using MacOS I often forget there's a menu at the top of the screen. Because I'm so used to apps that have in-app menus (Chrome, Slack, ..)

I think the author is confusing two different things, the app menu and the app name indicator (one has to click the indicator to raise the menu). I thought the plan was to remove the menu, not the indicator. The author defends the "Appmenu" because it serves as a landmark, "on Gnome 3, I can always tell exactly where I am". To serve that function, one only needs the indicator.

Yeah that's one of the more direct criticisms I had as well, just like the author

- not realising that (though this is an assumption from me) the most common workflow in GNOME is for applications to have a single window, i.e. users not being aware of distinctions between windows and applications. - thinking that you can only interact with focused windows. The result is that on multiple monitors, you don't need to be constantly aware of which window is focused - except to know which window's menu bar is currently showing.

That said, in broad lines I'm mostly annoyed by the author's trivialising the reasons for things not being the way they'd like them to be, and placing their own intuitions over actual user experiences - as an interaction designer.

It's like park architect that create what they think are beautiful paths that surely everyone will like, only to end up after some months with with organically created paths made by users walking on the lawn.

The best way is to create the park with no built paths, let people settle in for some months and then come and build over the paths they created themselves.

By that logic you define the park as a part of the way from A to B and whoever comes first and is part of the majority who wants to travel from A to B through the park without casually strolling will define the way. What if the park is supposed to have a few loops and not-directly-diagonal paths to encourage lingering around?

Also, maybe I'm just the stereotypical boring German but I usually try to not use the man-made footpaths if I just have to walk 20m more... Of course that's different for really "useless" 2m x 100m stripes of lawn in the middle of nowhere where someone just didn't notice that everyone will have to cross it, but of course there are exceptions to every rule.

In chicago, at Illinois Institute of Technology, they had a park in-between the residencies and classrooms; when they decided to build a main center (McCormick Tribune Campus Center) at the park, they (Rem Koolhaus) tracked the pathing that students were naturally taking to cut through the park, with the assumption that these were naturally optimized routes to important destinations. The building was then constructed such that those pathways persisted. This worked out quite well, in usage. (except some of the administration doesn't actually grasp this concept, and arbitrary block off routes... most often for their security circus)

>whoever comes first and is part of the majority who wants to travel from A to B through the park without casually strolling will define the way

I'm not sure about whoever comes first; people don't normally follow paths based on lightly treaded footprints in the grass. Hell, you watch people cutting across the grass and you're not going to see them just line up.. They walk to their destination, and enough people to do so over the same path (presumably, because its optimal, or close to it), and the grass dies, and a pathway naturally emerges, and then you get your lines. It wouldn't be about which person arrives first.. it would be about which destination appeared first. The pathway would be naturally created for it, and then if a different, but nearby destination appeared, they'd probably re-use the pathway rather than to create a new one. A sufficiently distant new destination would likely create more pathways though.

>What if the park is supposed to have a few loops and not-directly-diagonal paths to encourage lingering around?

There's nothing stopping that; just don't interfere with the optimal paths. There's no reason you can't have more paths (it's not like you're putting fences so they can't intersect..), but certainly its unreasonably to have fewer paths than what people will naturally use.

Also, what is this supposed to business? It's a design/aesthetic choice, and if its unreasonable to have given the conditions of the environment, it would be utterly moronic to put it in anyways. If the designer doesn't have the authority to not be subservient to whatever is supposed to be, then its likely the stupidity of the bureaucracy. This then isn't question about what is good, its about what the authority thinks is good, and by how far its willing to force it onto the population.

I applaud your example, but "park between residencies and classroom" is exactly what I meant. It's nicing up the area that's being used daily by loads of people with a deliberate path. For me "park" usually means "recreational area that doesn't happen to intersect the main pathway". And if it does, yes, sure, please make the direct route accessible so not every bit of lawn is treated as a footpath.

Maybe I'm more thinking older cities like where I live where they sometimes convert old graveyards not being used for 200 years and having many graves of well-known architects, inventors, etc to parks, but not in the "play football on the grass" parks, but shady paths to take a stroll and sit on a bench.

Hmm, I'm less convinced about gnome3. I've given it a number of goes, it shows promise, but is not there yet.

1) its too godamn slow. I have 32 cores, 64 gigs of ram and a massive graphics card, yet draging windows about has lag, pressing the meta key has lag. Its just not fast like mate or lxde.

2) shortcuts are hard. I have a number of shortcuts for my most often used things, and they are always clickable, no matter what. Gnome 3's favorites are _almost_ the same, but its much harder to create custom entries (if its not in the applications list you're out of luck)

lxde for the win! Seriously, I run it on a 12 year old laptop, and newer laptops and htpc's. It just can't be beat, in my opinion. The simplicity and customization is its power. I enjoy it more than xfce or mate. Though to be fair I have no tried mate on a non-ubuntu flavor.

I agree with that :) Though after a while I personnally traded simplicity* for more customization and performance and switched to openbox and now i3.

Edit: * Well no, "simplicity" does not exactly mean what I first thought it did. I guess I mostly traded ease of configuration / usage. Openbox and i3 are more difficult to approach but they don't lack on simplicity at all.

The one laptop I have running a Linux Desktop runs lxde, and it is pretty good, but I wouldn't say it's very customizable. Maybe I haven't spent enough time with it, but how do I add custom menu entries, for instance? How can I add additional menus to the panel? I miss Widowmaker/GNUStep, which still exists of course but no distro on earth uses it by default and Linux Desktops are enough of a pain to build from the ground up that people keep making distros with minor tweaks just so they don't have to do it again.

GNUStep could’ve been a contender. In an alternate universe, Gnome & KDE never fractured the desktop Linux space, and GNUStep became a first class alternative to macOS, eventually surpassing it.

>1) its too godamn slow. I have 32 cores, 64 gigs of ram and a massive graphics card, yet draging windows about has lag, pressing the meta key has lag. Its just not fast like mate or lxde.

I am going to say this is probably only partly GNOME 3's fault. I have only lukewarm feelings about GNOME 3 but was blown away when I ran a distro on a very old Intel NUC only to see GNOME 3 running buttery smooth.

My guess for why is due to the high quality of the open source Intel graphics accelerator drivers on Linux. NVIDIA and AMD do not offer this at all, and at best performance can be tricky depending on what extensions and features your driver supports (and how well your card is supported if using open source drivers.)

Basically, I don't think GNOME 3 is bloated or slow. I think it uses relatively reasonable CPU, but compositing in Linux is complicated due to second-class graphics driver support, and that causes a lot of the lagginess/glitchiness/general wonkiness that you get with the desktop experience. (edit: An example is that I've had issues with resizing Windows that I have found to be NVIDIA-specific.)

(Of course, you can get around this by not using compositing at all, but I think the case for compositing is more than solid at this juncture.)

AMD and Nvidia both have better drivers than Intel, although admittedly Nvidia only offers proprietary drivers.

There is a open source NV driver which is usually the default that gets installed and it really really sucks a lot.

Its the first thing I banish on any image I create.

In my experience, the Intel drivers are always the most stable and the closest to their Windows performance. Although I haven't tried the new AMDGPU yet.

Gnome IS slow. Have you used unity 7? It has more animations and effects but still performs way better than gnome3. Gnome3 isn't bloated, it's just written with js. Plain and simple.

It's known that driver support is bad. But I think the main problem with gnome is that it uses js. Its runs a whole damn browser (firefox). It's js that owes to the numerous memory leaks that end up hogging extreme amounts of memory.

To build on this: even KDE tends to feel snappier than GNOME3. That's even if I'm going crazy with transparency and wobbly windows and 3D-cube-virtual-desktop-switchers and desktop widgets and all that.

Transparency, wobbly windows, 3D-cube-virtual-desktop-switcher and desktop widgets shouldn't make any impact on any computer with hardware made since like 2007. Windows Vista did it in 2006, and it's 2018 now. We have phones with better hardware than we had at the time.

Gnome 3 isn't "written with JS." I am aware that a large amount of gnome shell is written in JS and I have my opinions about that, but they have their reasons. Either way, the bulk of important code (Gtk, Mutter, etc.) is written in C.

Also, I don't think it's unlikely you found different desktops that perform better. I still find KDE on proprietary NVIDIA to be lackluster. Does it show it's possible to do better compositing on some setups? Yes. I am guessing GNOME relies on the existence of certain GL extensions to composite efficiently. Still: if it can perform well on super low end systems and poorly on high end ones, I doubt it has to do with JS.

I was not necessarily talking about performance when mentioning JS. It was the memory leak. Gnome performs "fine?" at bootup, but starts becoming sluggish as you use it because their JS interpreter doesn't automatically have GC. This kind of behaviour is fine for websites since nobody really uses it for an extended period. But for a desktop (which I for once, use for quite long stretches) is unacceptable. I've had cases where I had to forcefully reboot the machine because gnome froze.

Even if you ignore the memory leak (and say that it's being fixed) I would argue that the overall latency of the desktop is just not there. I have used xfce, gnome3, unity7, kde, mate and budgie (daily driver) on the same machine, with the same Intel iGPU Mesa driver; gnome3 is the most sluggish. The time it takes for stuff to happen on the screen from when I press a button is quite high for my taste.

P.S. I usually disable animations.

The design of the desktop is definitely unique and admittedly refreshing to see (except the hamburger menus). However, the sluggishness just makes it impossible for me to use.

Oh, and Gnome3 is absolutely "written with JS"

https://gitlab.gnome.org/GNOME/gnome-shell/graphs/master/cha...

> bulk of important code (Gtk, Mutter, etc.) is written in C.

Exactly why budgie desktop is fast. Uses Mutter as WM, and the gnome applications (like Nautilus, control centre).

For instance, gnome-shell starts up at around 150MB of memory usage, climbs upto around 1GB, eventually halting.

OTOH, budgie-wm stays at a cool 25-30 MB usage.

More on how the budgie thing works : https://budgie-desktop.org/2017/01/25/kicking-off-budgie-11/

> NVIDIA and AMD do not offer this at all, and at best performance can be tricky depending on what extensions and features your driver supports

Desktop environments usually rely on the most basic features.

Games or Unity desktop somehow manage to perform well with their animations with the same drivers.

I'm using the closed nVidia drivers because everything else is an act of madness. (why else would you buy a powerful graphics card if you're not going to use the drivers!?)

As a comparison, using kivy (https://kivy.org/) I'm getting constant 60 fps at 4k (I have vsync on and full compositing pipeline to avoid tearing)

Compositing in gnome2 was never a problem (once it was stable, back in late 2009) I don't see why its should be a problem with gnome.

Now I'm willing to admin that compared to a web app, its snappy. But thats still not fast enough.

I use the nvidia card for games, but intel for the desktop. It's much better.

Could you please elaborate a bit on your setup? I don't even know how to check which card is doing the rendering, let alone how to switch it.

> My guess for why is due to the high quality of the open source Intel graphics accelerator drivers on Linux. NVIDIA and AMD do not offer this at all

Serious question: Is your opinion of AMD based on the old radeon driver, the old Catalyst driver, or the new amdgpu driver? Those are three entirely separate and vastly different experiences. I'm using amdgpu at home and have not experienced any performance issues with it at all.

I've been using amdgpu for a year or so (though I just recently stopped, due to computer changes) and it's better yeah. I had a bit of stability issues but it might've been the card.

>I am going to say this is probably only partly GNOME 3's fault. I have only lukewarm feelings about GNOME 3 but was blown away when I ran a distro on a very old Intel NUC only to see GNOME 3 running buttery smooth.

Not true. It is 100% gnome's fault. I've used gnome 3( fedora) and I have played a ton of games on the same intel laptop and I have noticed gnome lagging a lot more than any other environment I have ever used. There is a reason for that: Everything is in one thread, including plugins and the js engine and runs on the cpu( no kidding).

https://anholt.github.io/twivc4/2018/05/30/twiv/

I believe that’s something that is being seriously considered, see https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeS...

The slowness was very apparent for me too. I used to keep restarting the shell (Alt F2, then r) to get it back to normal speeds(this doesn't close the running applications).

In Wayland, they removed this shortcut. I've since switched to KDE.

You can blame js for that. It's known as the famous gnome memory leak.

Modern KDE also uses JS.

So I guess Qt's implementation is of better quality.

Qt projects tend to use js as the js was originally intended: small one-liners (in this case, to glue some QML together).

> In Wayland, they removed this shortcut.

I'm usually not one to come to Gnome's defence, but it's very likely they did not really have any choice there. In Wayland, the compositor is the parent process of the entire session, so you cannot restart it willy-nilly. That's a design choice made by the Wayland protocol, not by the Gnome devs.

The real problem was that the shell got slower over time. If that was fixed, the choice of Wayland vs. X wouldn't bother me.

Gnome is slow because it uses js. I don't understand how anyone would agree that using js on a desktop is a good idea. Goddamn, designers...

This website shows how input latency has become worse over the years [1]. On the bottom there are more references, such as a comparison between terminals and editors (not that you asked for that, but still).

[1] https://danluu.com/input-lag/

This started out as an overview of a new desktop bundle and quickly turned into a rant about why gnome shouldn't change your favorite feature..

Yes, indeed, and Balkan's favorite feature is my personal most hated feature. To each his own, I guess...

Menu's belong on the app window.

I just want that quarter inch of screen retail. Why can't they do the Unity desktop thing and merge the top bar together?

unity was almost perfect. And then ... :(

But there is a buggy extension just for that.

Whether you agree with him or not, he made several arguments for disconnected menu bars. What are your arguments for having menu bars on windows?

It increases the cost of all menu interactions with non-focused app by one click. I'm not sure if gnome 3 duplicates that menu bar on each monitor, but if it doesn't then it means significantly more steps (strictly speaking) to locate the app, locate the menu bar, return to the app.

It also encourages a poor menu paradigm (imo) of nested menus. Iconography, ribbons, searchable action bars, and other innovations are more often found on OSes where the choice isn't made for the user.

It seems really silly with how UIs have evolved to use a Mac at work, with half of the menus in the app and a seemingly random other half in a disconnected set of nested menus. That's my experience at least.

For a UI consistency is better than dynamic elements. In fairness this can be used as an argument in favor of the global menu too, depending on exactly what you want to be consistent.

Linux desktops are usually "focus follows mouse" (because the scrollwheel is part of the mouse not the keyboard), so in the second screenshot with two apps side by side and the right one in focus, moving the mouse to the menu will result in the active application and menu changing.

Focus follows mouse breaks if you need to move the mouse away from the window over other windows to the top bar.

Focus follows mouse is an extremely useful feature which allows you to move focus without changing the relative arrangement of windows to each other (whereas Alt+Tab or relatives would bring the selected window to the front).

Additionally, a top-level menu bar is always there and requires a horizontal layout (I think?). In a window, each application can decide to hide the menu bar at will with only a vertical panel being visible at all time in all apps.

Regardless, GNOME is going to do something which is many times more terrible than having a global or local application menu. They are going to put everything into hamburger menus:

https://wiki.gnome.org/Design/Whiteboards/AppMenuMigration

I can see why the hamburger menu works for a constrained space (such as a smartphone), but for a laptop or desktop, it is absolutely terrible: place for less menu items, another layer of navigation (since you cannot cram everything in one menu), and in the GNOME case typically no visible keyboard shortcuts.

The Xerox Star had hamburger menus, but Apple Lisa and the Macintosh moved away from hamburger menus because regular menus had better discoverability and required less clicking accuracy [1]. We are moving backwards when it comes to user interfaces. Luckily, it seems that this disease hasn't really spread to KDE or macOS yet.

Unfortunately, in GNOME, the application menu was already pretty useless, because it had many items already moved to the hamburger menu or simply removed.

[1] https://medium.com/@probonopd/make-it-simple-linux-desktop-u...

> Regardless, GNOME is going to do something which is many times more terrible than having a global or local application menu. They are going to put everything into hamburger menus:

It's amazing how even the mockups on that page are obviously for phones or tablets.

On the one hand, I while I don't use it anymore, I do wish desktops were more of a first-class citizen for Gnome, since it's the default environment on many distributions.

On the other hand though, I really wish designers involved in Linux FOSS projects would stop shoving designs made with smartphones in mind on the desktop. Running Gnome on a 27" screen -- and Gnome applications -- is a really confusing (and, at times, outright hilarious) experience, it's like I'm moving iPads around on my screen. Maybe this is a step in the right direction.

How are such decisions made in Gnome? Who decides and how do they enforce it? Will it be salaried developers that adjust the applications?

RISCOS made a pretty compelling argument, I think, that all menus should be context menus. I'm not sure I agree, since it reduces discoverability, but I do think it otherwise had all the Fitts's law advantages of a global menu bar while still making the association between the menu and the application obvious.

Exactly. The article went off point very quickly, in my humble opinion.

Oh, no worries there: if it’s your favourite feature, I can pretty much guarantee that GNOME will remove it someday.

It’s what, a decade now, and we still don’t have screensavers back, let alone configurable screensavers.

Window title bar heights are awful. Title bars at the best of times are just a useful thing to grab with the mouse pointer to move the window around, but they don't have to be about twice the size of those in Windows and MacOS.

If anything, on Windows the trend is to use the redundant window space to add more information.

I've never quite understood this decision on Linux. If anything it seems a little contrary to linux usage.

They look about the same as Windoze 10 to me, and they do seem to have stuff in them, so not completely redundant. I still don't like it, I like extremely minimal window borders (I hold alt to move windows around). But you can get that on Linux, and only Linux.

It's a GNOME3 thing, not a Linux thing. Most other desktop environments (including GNOME2/MATE) have more sane defaults.

As for the reason why GNOME3 has window handles the size of interstate freeways: it makes them easier to move around with a touchscreen.

> it makes them easier to move around with a touchscreen.

Ok, next question: Why do you need window handles the size of interstate freeways on devices without touchscreens? It's not like it's impossible to detect the current hardware configuration.

If you want to see what Armaggedon looks like, try suggesting that something should be user-customizable or that it should change depending on the underlying configuration on a Gnome mailing list.

>Ok, next question: Why do you need window handles the size of interstate freeways on devices without touchscreens? It's not like it's impossible to detect the current hardware configuration.

Because options run counter to the gnome dev philosophy. That can be traced back to the original Havoc Pennington rant to defend Gnome 2.0 (which was actually a controversial release just like every major gnome release since 1.4) : https://ometer.com/preferences.html

>Preferences substantively damage QA and testing.

>As someone who reads dozens of bug reports per day, and occasionally fixes a couple, I can tell you that it’s extremely common to find a bug that only happens if some certain combination of options are enabled.

>Upshot: more preferences means fewer real features, and more bugs.

Of course, what you propose isn't a preference but automatic detection, but the point still remains valid in terms of their philosophy.

>One of the hardest lessons of GUI programming is that hard coding behavior can be the Right Thing. Programmers are taught to make everything generic and infinitely flexible. The problem is that the more generic and infinitely flexible your UI is, the more similar it is to a programming language. Lisp is not a good user interface.

These are the same reasons why they canned anything related to screensavers and the likes. Gnome should not be customized, should have brand identity, should not have options whether they are user selected or automatically configured. The UI should be recognizable no matter which device Gnome is run on. Anything that changes confuses the user. If the user installs gnome on a laptop with a touchscreen, what should an automatic configurator the likes you suggest do? make everything tiny so that it's friendliest to screen space since it's a laptop and touchscreen is only sparsely used? or make everything big?

A touchscreen is a different device than a desktop computer. Would windowing make sense on an iPad? Probably not. So why make people use them? Same goes with a desktop - they are designed for the mouse, so design it to use a mouse and do t treat it like a touchscreen.

This often means UI preferences. And I’m afraid you cannot satisfy everyone’s preference. Havoc Pennington was right to a degree, but they have tended to take it too far.

What the heck? 90% of the article is just ranting about a Gnome feature; I still have no idea about why Pop_OS is the “state of the art” because the author literally did not provide any commentary on what makes it unique except for a brief mention of it curating various things.

This is bad writing.

Agreed, after getting halfway through I couldn't finish it as it turned into a mindless rant.

The idea that Linux needs consistency is correct,albeit difficult to achieve. I doubt pop os will make 2018 the year of the linux desktop. Making every app conform to the gnome guidelines on an underdog desktop platform where many interesting software is just crossplatform (java apps, electron apps, browsers) and do not have an interest in a specific toolkit.. is quite a dream.

I don't know why the article didn't mention the most prominent technical features of Pop!_OS that propels it beyond being a mere copycat.

* HiDPI Daemon: They wrote this themselves and what it does is if you have mixed DPI monitors, it auto-detects and conforms them to the lowest common denominator. Wayland does this by default but support for Nvidia isn't there yet and applications like Firefox don't reconform between monitors.

* Systemd-boot. GRUB is the past. Systemd-boot is life. Faster startup to desktop.

* Do Not Disturb and performance profile picker from the menu bar.

* Dat installer. They collaborated with Elementary OS' Daniel Foré on this. It's polished, easy for anyone to grok, offers simple full-disk encryption, and and creates a recovery partition in case you hose your install.

System76 has really thought through these usability improvements to bring us a desktop that anyone can use and encourages security out of the gate.

This is surely just an ad. The sheer amount of superlative breathless enthusiasm is overwhelming.

And, it's yet another ubuntu derivative.

...which is yet another Debian derivative.

A Debian derivative it may be, but as the server OS with the biggest market share, and also the most widely used Linux desktop distribution, it's hardly 'yet another'

It's yet another. It still repackages debian unstable, kinks and all. At best it adds value through maketing while piggybacking on Debian's work.

You’re quite right that it’s the server OS with the biggest market share, but I seriously don’t understand why. I get why folks like Ubuntu on their desktops — it’s nice & bleeding edge, with all the latest gee-whiz gadgets and tons of proprietary drivers — but why would they use it on a server? For a server one ought to prefer stability & maintainability, no? And for me, that means Debian.

While technically true, a ubuntu derivative carries, by virtue of ubuntu, a shit ton of non-upstream patches than debian... and, by definition, a shit ton of non-free software than debian.

I have to admit I had the same thought, but seeing it backed by System76 does give me a lot of hope that it won't be another "flash in the pan" novelty distro that will disappear off the face of the earth in 12 months' time.

Hardly. The article turned midway from explaining why Pop_OS is well designed to why should Gnome not remove a feature from their project.

Have they patched the Web application to work with dark themes properly? I tried using it but every textbox imports the background color from the desktop theme (good) but it uses the page assigned text color, which is nearly always black, so you end up with every textbox having black text on a black background, making it unusable.

Firefox has this behavior now too.

I was able to workaround the issue in Firefox by overriding the GTK theme ( https://askubuntu.com/questions/8336/how-can-one-make-firefo... ) and then applying a Firefox-level dark theme.

In my experience, Chrome appears to ignore GTK-level themes entirely.

Longer term, this will be fixed when https://bugzil.la/1411425 is resolved.

From the comment on the issue:

> Due to various various theme issues between platforms and HTML native theming, among other things, native theming should be removed entirely and instead replaced with internal 'native' elements in the browser itself.

Why are so many developers keen on stripping features instead of just making it optional? This isn't just some unfunded open source project.

I know its petty, but that colon in the clock on the main image really bothers me. Its way too chunky compared to the numerals.

I too have to disagree with the author based on my experience. I use Gnome 3 at work, every day, and both my home computers are on Gnome 3. I use the Pop Gnome theme from the very people the article talks about (System 76), it's a beautiful theme and can be installed on Ubuntu using their PPA.

Anyway, At home I also use 3 monitors on my desktop. Lets say I have a "normal" sized terminal open on my right hand of 3 monitors. It's on the right one because my IDE or such is sitting in front of me on the centre monitor and as a lefty I tend to "prefer" the right to the left as I sit looking at my PC. I'm sitting with my chair shimmied to the right of my desk because these monitors are 28" each and I decide to move closer to that window to see what's going on because they're 4K monitors and the text isn't huge. I'm physically about ~4 feet away at the extreme in terms of mouse movement, from that app menu on the top left of my left monitor.

As someone who tends to fill all of this screen space flatly with tiled windows as opposed to stacking and switching them, all I want is for every menu for every window to be directly attached to that window, because the "landmark" for me is the window itself.

Having to move my mouse, 4 feet across displays to get to a menu for a small window I have open and happen to be working on at that point in nonsensical.

I might have 16 terminals tiled across that display, if I want to interact with a specific one, lets say to change the background colour for identification or something, the first place I'm going is to the window itself.

My solution, is that by using Gnome Tweak Tool, I have the button on the title bar of the window instead of in the panel.

I switch between Manjaro with Gnome3 on my laptop and Mint with Cinnamon on my Desktop. When i use gnome it annoys me regularly with things like:

If i want to open a file in a different program than the default i have to open another menu instead of immediately being shown the other programs being associated with that filetype.

Just connecting to wireless took me approximately 10 Minutes.

Hiding the topbar automatically to maximize the screenestate on my 13" screen is not possible without installing an extension, which last time i looked was not ready for 3.28 and could crash the session if badly written.

This guy talks about how important this Appmenu is, which rarely contains useful options if any.

He claims he tried Linux Mint, but for me Cinnamon is far ahead in usability. The Mint devs actually listen to their users and work on solving their problems.

I've tried Pop OS, but it seems little more than a GNOME theme to me.

I also don't understand why they didn't pick (or better yet fork) elementary OS, which is the only good-looking Linux distro that has a different enough vision to justify the duplicate effort to create another distro.

Personally, I think that GNOME is completely unusable. Pop OS is too close to GNOME. elementary looks great but its minimalism is similar to that of recent Apple--where so many features are removed that the app stops being useful, and huge compromises are made just so the thing looks good, ignoring that it has a purpose.

I'm using an heavily-modified Xfce install and I can actually manage to be productive.

I don't think this really qualifies as a new disto. Maybe should have been named Pobuntu so people would know what they are getting. Wish a desktop focus disto would come out that would make it so people didn't have to feel like sysadmins to use a linux box. Simpler to toss some new paint on someone else work, and call it their own I suppose. I am going to hard pass on this one though stick to my lxde since it does everything I need. Plus I spend 90% of my time in a terminal so icons don't mean much to me.

Some interesting points here regarding design improvements to bring us a more mainstream Linux desktop, but what about price point as well? I just configured a System76 Gazelle laptop with the same specs (albeit newer cpu, but moore's law) as my 2 year old ideapad and it's $400 more than what I paid back then.. AND no gpu either. :/

Reads a lot like an ad. So far nothing beats my experience with i3wm on Arch Linux. I can hardly imagine going for any other system setup after trying this combination out. Well, maybe another even better window manager, but definitely not any non-wm UI, which will only be clumsy and horribly get into my way.

I have a System76 Galago Pro, and I'm a big fan!

It's been a joy to use, and fits my use case well.

It has rather terrible battery life, but I tend to just plug it in wherever I go anyway.

I like almost none of this and disagree very strongly with many of the assertions of what is good and what is bad.

I imagine this is the last we'll hear of this anyway

Hmm, I've tried Pop OS a year or two ago, and I wouldn't call it state of the art. I'll stick with MX17 when it comes to Linux..

What laptop is that? The one in the first picture?

Looks like a Dell XPS 13.

Started off as a great article. Turned into an endless rant that's entirely ignorant to the idea that maybe what works for you doesn't work for me. My eyes eventually got fatigued from the constant rolling, and I stopped reading at some point.

The whole rant ends up boiling down to putting form over function, which I think is backwards relative to good UX. The form should absolutely be dictated by the function.

Now, there are a couple points of (what I read from) that rant with which I do agree:

1) The insistence upon shoving everything into a hamburger menu is asinine.

2) The insistence upon shoving a mobile-first UI paradigm down desktop users' throats in general (an example of which being the previous point) is asinine.

2) It makes sense to have a visual distinction between application-level and window-level operations, and to have those operations segregated into their own respective application-level and window-level (e.g. task-level or document-level) menus.

Where I strongly disagree is when there's this strange assertion that there should only be one application menu displayed at any given time. That falls flat for several reasons:

1) A monitor may have multiple applications visible

2) A set of monitors may have multiple applications visible even when each monitor is dedicated to a single application

The solution - in my mind, at least - would be to make sure that if an application's windows are visible on a monitor, then the application's menu is visible on the monitor somewhere (and if the application has no visible windows, then feel free to hide the application's menu somewhere out of the way. Whether that menu is attached to each window or to the monitor itself can (and should) be up to the user's preference (I have no objective opinion on a default setting for this, though personally I'd probably prefer these application menus to be in the status bar for the same reasons as the author articulates). Hell, if the user wants to pull a NeXTSTEP and not attach the application menu to anything, then go for it (I probably would not want this as a default, but hey, if you're going for a classic NeXT aesthetic, then you do you). User wants all of the above? Maybe a bit redundant, but if that makes it easier for the user, then why not?

This works great no matter the form factor. Larger screens would be more likely to have multiple applications on display at once, and thus would show multiple application menus. Smaller screens would be more likely to have one (or at most two) applications on display at once, and thus would only need to show one or two application menus.

In the case of a monitor-level menu, the function here may or may not overlap with a dock or some equivalent interface element. I'd probably combine the two in that case. App launching can be done through a single Activities/Launcher button (with "pinned" and/or running-but-not-currently-visible apps being front and center). Managing running apps can be done through the app's menu, whether the app's visible (and thus would have a visible menu on the monitor's bar) or not (and thus would have a menu hidden somewhere but still readily available, e.g. in a context menu - or hell, an actually-visible menu - on the app's launcher icon).

In the case of an application-level menu on each window, I'm envisioning something like the menu Firefox (IIRC) used to have at one point: a button by the window controls (or maybe at the other end) with the application name and/or icon as the label (plus a window-specific title for the window itself). A hamburger menu icon might also make sense here to signify that this is in fact a menu, but that should be in addition to the application title/icon, not as a substitute.

In any case, if a window is visible, its application is visible. The user can quickly find the application menu and perform application-level tasks (like opening a new window) without necessarily needing to perform a separate action of switching focus to one of that application's windows (this is a reason why I agree with the author about detaching the app-level menu from the window: much easier/faster to find when it's in a consistent spot).

In summary: a hard-to-use interface is poor UX by definition, regardless of how "pretty" or "elegant" or "minimal" it may be. Good interface design means making common things easy while keeping uncommon things at least possible. If the interface is a little cluttered as a result, then so be it.

> Unlike Windows, there is no ungainly multi-level start menu from hell.

I wonder which version of Windows the author used last.

What's funny about this is that I and many others use Classic Shell to get exactly this "multi-level start menu from hell" back in Windows 10.

On Linux I only use Desktop and Window Managers that I can configure relatively freely and easily. No need to patronize users.

Old school Windows start menu was a great menu. It was just a menuized folder hierarchy, simple and effective. The only real flaw was that you only had one, you couldn't add new "start" buttons pointed to different folders for custom menus.

At some point they added the ability to kinda do that, (right-click taskbar -> new toolbar...), which still works on Windows 10.

puh-leaze. Just another Gnome derivative.

Reply on news.ycombinator.com