libadwaita and Kirigami are huge improvements for the desktop app ecosystem from what I've seen as a user. When I started to delve into desktop applications I quickly realized there's a couple hurdles I face:
1. QT was an ecosystem shock to me. I barely knew what to do to get started and got lost easily.
2. Do these applications work outside of Linux; more directly, do they have dynamic dependencies? From my experience, the former is difficult and the answer to the latter is yes.
3. The lack of library support for Go and Rust is notable. Sometimes I want to throw a UI on top of what used to be a terminal app written in Go (or Rust).
You wrote: <<QT was an ecosystem shock to me. I barely knew what to do to get started and got lost easily.>> This is surprising to me. It is the gold standard for cross-platform desktop applications. (Readers: Please note that I used "cross-platform" and "desktop" _together_. Yes, I know there are plenty of other GUI frameworks that cover other categories.) The amount of official and unofficial documentation, code samples, and Q&A for Qt is simply mind boggling. Did you not find these docs helpful? Or maybe you do not like C++? Lots of people also use PyQt (or variants) with Python and get along quite well.
Also, if Qt isn't good for you, what else did you try? My experience with GTK+ was awful -- bizarre API and terrible docs. Further, the community was unhelpful and borderline trollish. This was well-documented by the "Subsurface" team (SCUBA diving software) during their transition from GTK+ to Qt.
It used to be much more involved in the past. Of course you could hand write the code, but as it was originally I believe a preprocessor was the only way to sensibly write signal support, something that AFAIK stopped being true around 2003 but by then moc was entrenched.
libAdwaita is an attempt at providing a consistent framework for making GUI applications in Linux.
People commenting on MacOS UX often forget that people creating Mac GUI applications aren't magically better at doing UX than Linux users. It's orders of magnitude easier to make ok looking GUI applications on a mac.
Besides the fact that cocoa on mac has evolved over a decade(when linux people were busy constantly reinventing gtk themeing engines and display servers), cocoa had more books on building gui applications in ~2010 than the entire history of gtk and gnome together.
And while the gnome team is busy constantly tweaking small visual details, glib is still a nightmare to work with.
It's also full of ticks in places you'd think should be fixed by now. For over a decade selecting folders in gtk/gnome has been broken by design:
- open folder selection dialog
- click a folder by mistake without double clicking it
- clicking the select folder button now enters the folder instead of selecting the current folder
- there no way to unselect the selection. -> you have to enter the folder, then go a level up and then select the folder
Kirigami looks promising, but it doesn't look anywhere near production quality polish.
> - open folder selection dialog - click a folder by mistake without double clicking it - clicking the select folder button now enters the folder instead of selecting the current folder - there no way to unselect the selection. -> you have to enter the folder, then go a level up and then select the folder
Glad I'm not the only one with this problem, it's so frustrating and there's literally nothing you can do about it, you just gotta go up one level and come back down.
> Besides the fact that cocoa on mac has evolved over a decade
Arguably longer -- Cocoa itself goes back to NextStep in the mid-90s, and the Mac focus on UX goes back a decade before that.
But, I don't think it's just the books -- starting with the NextStep era, the tooling (Xcode and, before that, Interface Builder) was part of it, and the whole "follow the Human Interface Guidelines" ethos going back to the 68K Mac days genuinely created a culture of UI-obsessed nerds, not just inside Apple but in the whole third-party developer ecosystem, that I haven't seen anywhere else. While I genuinely don't think it's fair to say that open source developers don't care, they don't care at the same level that the Mac historically has, and you see that in all sorts of tiny little details that seem individually inconsequential -- like the "broken by design" folder selection you describe above -- but collectively add up.
Well, I'll back off the "haven't seen anywhere else" a bit; I met a couple folks working on Qt when I was at Nokia circa 2010, and they seemed to be that level of deeply involved opinionated UX nerd. (Which genuinely surprised me, I confess, because my impression of Qt before starting there was…maybe not the best?) But it's not something I saw carried through by third-party Qt developers outside Nokia/Trolltech.
One could make a good case that Apple's taken their eye off the ball in terms of UX over the last few years, making unforced form-over-function errors and biffing aesthetic details in ways one suspects they just wouldn't have a decade ago. Even so, there's a cohesion to the design that I don't generally feel on other platforms. I'm not convinced the "convergence" that the linked article described is the way to go to address this, either. (As others have pointed out, the apps Apple makes using their own "convergence-focused" toolkits like Catalyst have tended to be their wiggiest.)
Yes MacOS and Cocoa is just Nextstep. Not only are the classes called NSSomething, but there is a presentation from early 90ies of the dev environment by Steve Jobs and the Interface Builder etc look very similar to Xcode.
> People commenting on MacOS UX often forget that people creating Mac GUI applications aren't magically better at doing UX than Linux users.
It's not magic. It's attraction. Just like magnets. People who _care_ about UX are more likely to use a Mac than any Linux distro. Independently but related, those who use a Mac are far more likely to care about UX than the average Linux user.
I say that as someone who dremels their phone and earbuds to make them easier to use, yet still prefers a Debian desktop.
The argument isn't that one _could_ dremel Debian, in fact, after recently installing KDE on a new machine I'd argue that one _has to_ dremel it a bit to get a good UX. The argument is that the Mac - for all its flaws - has a better UX.
People who care about UX will gravitate towards the Mac. A subset of these folks start developing software, as a consequence, the people creating Mac GUIs do better UX than those using and developing for Linux.
Yeah, you see that's where I don't think it's "people who care about UX" who gravitate to Mac. Maybe 10 years ago, sure, when Apple font rendering was massively superior to anything else on the market and people would put up with endless crap with the corporate monster in order to not see ugly fonts. But these days, I'm not so sure.
The people who actually really care about UX want to dremel their stuff because the little tiny discrepencies annoy them (like you).
The people who flock to Mac these days are plain consumers. They want to be protected from the intricacies, have something that "looks good" without having to decide what "looking good" actually involves, or making any decisions about it. The average Mac user these days sees Apple as a brand that says something about their good taste.
and yes, I completely agree that you have to dremel your Linux install to get it looking good. But that's half the fun :)
> Besides the fact that cocoa on mac has evolved over a decade(when linux people were busy constantly reinventing gtk themeing engines and display servers)
I'll be the first one to concede that Wayland has been more or less a monumental waste of development effort, but can you point to the constant reinvention of themeing engines? Stylesheet modification has been a thing for decades now, there's very little that needed to be done to accomodate for them, at least from a GTK development standpoint (that I'm aware of).
A few minor critiques are in the wikipedia article[1].
Most of the ones I remember were theme developers dropping support for their themes during minor gtk3 releases. I remember seeing a lot of articles about this, but I wouldn't be able to point you to them now.
I've been experimenting with gtk-rs, but the GTK ecosystem is really difficult to get right. The examples are few and far between, and the type exceptions the macro DSL throws are very difficult to parse.
All the necessary components are there, but there just aren't enough guides out there to get started. I tried looking into how existing applications use the ecosystem, but experienced GUI developers pull tons of dependencies and use complicated code structures that are hardly documented.
I think switching from Python/GTK to Rust/GTK is probably an easy move, but as someone coming from .NET Forms GUI design, it's been tough getting into GTK. GTK Builder is supposed to have native support for Glade and all the other nice tools, but for me that either doesn't compile any code or refuses to even work at all.
Assuming you meant "GNOME" Builder rather than GtkBuilder (the template loader for GTK), I'm the author of it and can help figure out what is going wrong on your system wrt not compiling anything.
Just file an issue on gitlab and I'll take a look.
Usually when we come across bugs like this it's related to distro packaging as we have no hand in that and the Flatpak packages I maintain generally do-as-advertised.
I don't know what's wrong exactly, I think it's Flatpak related. From what I remember, it had something to do with a certain version of the GNOME SDK not being installed (I think it was looking for a version of something that didn't exist?) so it failed a dependency check when I hit the install button from the Builder popup. I think this caused the tool to get into a faulty state where it thought the dependency was installed but simultaneously suggested installing the dependency, so it freaked out. I'm usually working on Ubuntu so combining the outdated Ubuntu stable-ish packages with Flatpak's bleeding edge stuff causes issues from time to time.
This could've been a temporary problem and I could've had a streak of bad luck, or maybe my deskop and laptop are somehow just set up plain wrong. I'm no expert in Flatpak internals. I also don't have Builder set up any more so reproducing the problem is kind of hard. Next time I'm giving it a try, I'll try to keep in mind to actually post a bug report.
42 will be out in a couple weeks, and it has a lot of work to make flatpak stuff work better in the presence of "system" installations (rather than user installations where we normally install SDKs).
Hope you'll try it out! (It's also available on Nightly).
Is GNOME Builder intended to be usable as a general-purpose IDE, beyond just developing GNOME applications? It seems like with a bit of work it could be a very nice alternative to the usual picks.
There are really only a few of us that make Builder, mostly just in our free time. So that means we have to be very focused with our time and choose to focus on making it easier to write GNOME software.
That said, the whole thing is an open ended plugin architecture and we are very liberal about accepting all sorts of things. Many people do use it successfully outside it’s intended scope.
GTK and Rust works really well on Linux, which I suppose is the pertinent part given the focus of the article. I've yet to work out how to get GTK and Rust to work on macOS or Windows, which makes cross-platform UI difficult.
I built a new GTK 4 backend specifically for macOS so we have native support for rendering all of the UI with OpenGL like we do on Linux and Windows. I'm fairly quick to fix bugs if I get good reports, and it can be installed with `brew install gtk4`.
You can also build GTK for macOS easily with meson as it has subprojects for everything. In fact, our CI does it from scratch on every commit w/ macOS. On Windows you can just open GTK with visual studio and build it by using Meson to generate the project files.
A bunch of work is about to land to make the macOS backend more solid/faster too similar to the work Firefox did in the last couple of years to reduce power usage w/ OpenGL/IOSurface/etc.
Thanks. I'll take a look. I've tried Relm 3, Relm 4, and gtk-rs, but they all use Linux only in their CI. I just can't work out what to install and what env vars I need. I didn't the official GTK docs all that helpful on the topic. I'm keen to see how to package the whole thing up, too. Ideally, I could just put the necessary libraries in a directory with the executable.
Oh, nifty. I tried getting it going with msys2 and didn't have good luck. I think something might be conflicting. I haven't gotten to the point of wiping the machine yet. Maybe I'll have better luck with meson.
gtk-rs has a book[1] which has setup information for windows. The install was easy on windows following the instructions. I have yet to build an app with GTK4 so I can't comment on the writing and building of apps just yet.
I followed those as well but changed to whats in the gtk-rs book
A word of warning: before you start, if you choose to go down the MSVC path, you have to uinstall msys2 and remove msys from your environment paths. If the Meson build find msys2 in your environment path variable, it will try to build using msys2.
> QML is practically electron - it's runtime interpreted declarative UI plus a Javascript engine.
It uses significantly less resources and QML and QtQuick are pretty nice to work with compared to targeting a weird embedded browser with HTML, CSS and JS.
> practically electron - it's runtime interpreted declarative UI plus a Javascript engine
Except, none of that is what's wrong with Electron. What's wrong with Electron is the bloat inherent in being an entire web browser, and the fact that the DOM+CSS is terrible for UI development.
I'm so glad someone said it. I have long stopped working in GUI space, but I remember how horrible HTML/CSS is for app development and how great and flexible Qt was. Even more frustrating seeing where the industry is going now with Electron.
Nope. Electron is a whole browser under your seat, QML is a declarative language to instantiate C++ UI objects. The core logic of your application is written in C++/Qt instead of Javascript.
> QML still has only rudimentary support for AOT compilation
Fair point. But it shouldn't really matter in any application today, as your logic must reside in C++ models if you want to have real performance.
Real question: You wrote "responsive-layout desktop app". What do you mean by this term?
From my experience, if you develop Qt widgets (like dialogs with many child widgets), it is possible (some might say easy) to make things resize correctly by using QHBoxLayout (horizontal) and QVBoxLayout (vertical).
I meant "Responsive" to mean something like media query breakpoints - at certain widths, Telegram will rearrange entire UI elements and change the navigation paradigm.
qmlcompiler is open source and the new qmlsc is also open source. It's just the extensions that helps making your qml code compatible with the new compiler that isn't open source. This is indeed annoying but not everything is commercial only.
Where can I find the source code for qmlcompiler and qmlsc?
qmltc and qmlcachegen are available in the qtdeclarative.git repo (on either code.qt.io or GitHub) but i can't find qmlcompiler nor qmlsc anywhere. I believe they are commercial only under the "Qt for Device Creation" license.
For a Git GUI for Linux (and Windows), you might like GitAhead which builds under Linux? It's not under active development but has been forked to GittyUp: https://github.com/Murmele/Gittyup
I am very displeased by Snap being shoved down one's throat on Ubuntu. This has caused me to actually abandon Ubuntu completely. Linux mint and Debian now.
I replaced it on servers as well. Not immediately but after some extensive testing. I do not want to one day end up in a situation when snap will start displacing things on server as well and do auto updates.
Canonical really likes to develop their own technologies for some reason rather than use RedHat's. Upstart vs. SystemD, Mir vs. Wayland, Snap vs. Flatpak. Ideally there should be one standard for each with perhaps multiple implementations but for some reason it takes a lot of time wasted on duplicated effort before Canonical gives up. Not sure who really is making better cooperation here impossible but so far it seams RedHat's versions tend to be winning in the end, probably because they at least pretend to be openly developed with community involvement and don't focus on just one distro.
Seems like snaps were trying to solve a relevant problem (keeping software up-to-date quietly and automatically) but have a deeply flawed implementation. Almost daily I'll have Chromium suddenly completely break to the degree that it needs immediately restarting, losing all my open tabs/groups/auth. Working remotely with lots of web apps, this is a terrible experience for users!
I will never run your app if you build it this way, that sounds absolutely awful. Just write a GTK app or if that's too hard a CLI app since the CLI is first class on the PinePhone.
It's possible to design a ribbon bar that does not infringe on MS patents. IRC there are only valid patents for specific parts of the MS ribbon bar, not the whole bar.
"Although Microsoft popularized the term with a new meaning, similar tabbed layouts of controls had existed in previous software from other vendors, including 3D Studio Max R3 and later, Adobe Dreamweaver, Borland Delphi, HotDog and Macromedia HomeSite." https://en.m.wikipedia.org/wiki/Ribbon_(computing)
Yes, it's closed source. It's only free as in beer. Their website says: "What's the catch? There is none." It seems they offer this as a free product because they have a paid one with more features.
I presume things like making screenshots, browsing files, looking up contacts, maintaining a calendar, reading and sending emails, calculating some quick numbers, making backups and so on.
Stuff that, regardless of your niche, is needed. Whether you are a programmer or a plumber, you'll be doing many of these tasks on a daily basis.
Core workflows would then be composed of core functions. E.g. "look up a contact to schedule a meeting" would be a core workflow, composed of core functions addressbook + calendar + email.
These applications look really pretty and all, but for my selfish purposes, I just really want real goddamn scrollbars back. I use a mouse that doesn't have a scroll wheel, but for the life of me I've been unable to figure out how to make applications like Firefox just give me a real scroll bar on the side of the window that's thick enough to grab without fiddly pixel-hunting.
Those modern, 1-pixel wide, scrollbars that only expand when you manage to hover over them are a pox on usability. And I say this as someone with a mouse with scrollwheel.
They make it hard to see the size of a document and as you said: operating the scrollbar is fiddly. You can't just grab it. First you have to make it expand, then you have to move the mouse again to grab it, but don't move the mouse too much or the scrollbar will shrink again!
This is on both Linux and Windows. I have no idea what it is like on OSX.
Even worse. On MacOS the scrollbars are invisible by default, and only appear while you scroll, plus a second or so after stopping.
So to grab a scrollbar in MacOS you first have to scroll the document to make the scrollbar appear. Then you have under two seconds to move the pointer on top of the narrow scrollbar so it expands allowing you to grab it before it disappears again.
There is, and I'm pretty sure if you connect a mouse instead of a trackpad it enables by default. It took me a while to workout why I was seeing scrollbars again and how to disable it when I got a mouse.
I've recently installed https://addons.mozilla.org/en-US/firefox/addon/scroll_anywhe... in middle+right click mode, and now miss it everywhere I don't have it (Reader Mode, PDFs, etc.). Unfortunately development looks a bit inactive, and there's no option for locking scrolling into vertical-only if you begin a scroll by dragging vertically.
Yeah the scroll wheel was a big quality of life improvement when it came in. I wouldn't want to do without anymore. Though I mainly use pgup/pgdn to scroll. I wish the keyboard had a big scroll wheel. Some 90s keyboards did, like a big rod. But now if there is one it's for volume control only.
This is not true. On iOS I absolutely can grab the scroll bar and drag it around like normal. It even makes a solid click when the grab is active. It just isn’t super prominent like old desktop OSs had it.
I should have just kept reading. When I saw the parent comment it got me thinking I really should see how easy it is to change the scrollbar size in Firefox. Took me a few minutes to find exactly the instructions you shared.
Because if you have touchscreens you can use two-finger gestures, and if you're on a mouse you'll have no issue targeting a thin widget. It makes a lot of sense from that POV.
If the thin widget is directly against the edge of the viewport, maybe.
If it's literally anywhere else on the screen, then no, Fitts's Law applies, and it's a bad target. It has height but no width.
This is especially true for those with motor or visual handicaps, or both.
It's damned near unusable even with very modest levels of distraction or other factors, e.g., using a device as a passenger on a moving vehicle, as with a boat, train, or airplane.
> If the thin widget is directly against the edge of the viewport, maybe.
It is. Visually there's space between the scroll handle and the window edge, but if you actually point the cursor in that space it'll highlight the handle.
This feels pretty weird on macOS in a way I never realized, because I thought you were wrong but you're actually right -- you can slam the cursor right against the right edge of the screen and the scroll handle lights up and you can click and drag it if you start an up/down mouse motion -- but the cursor changes to the left-right resize one and if you start by moving left/right it resizes the window instead and the scrolling motion is cancelled.
I guess thinking about it this is a very reasonable compromise, but it feels weird to start scrolling up and down with a cursor that shows a left-right arrow and that is technically pointing outside of the scroll bar.
On KDE the cursor shape aspect doesn't match macOS (in the sense that if it's showing a resize cursor, it'll resize the window, no matter what), but per my comment further up the chain it'll absolutely work if it's just a normal cursor but between the handle and the edge of the window. Tried it on both Firefox and Konsole (which are subtly different due to Gtk v. Qt quirkiness but have the same behavior).
Though I'm using click-to-focus, not focus-follows-mouse, so YMMV.
NB: Trying on MacOS now, if I'm on a browser page in Firefox positioned within the display (other than at the right edge) and hit the right edge of the screen, the scrollbar does NOT in fact light up or activate.
If I have a window positioned to the right edge of the screen ... the scrollbar is draggable only when my mouse pointer is positioned directly over the scroll grabber. Not when pushed to the edge of the screen.
This seems to apply generally for windows best I can tell.
TL;DR: The behaviour you describe is not at all what I see.
This is a Firefox bug which has been open for years and years with no fix. Try it with native apps like Finder or Terminal. Absolutely works for me on Big Sur.
For a fullscreen window it would be nice if moving the mouse all the way to the right edge was sufficient to target the scrollbar, but that doesn't work in Chrome on my mac
You can also use the scroll wheel of the mouse just fine, or the TouchPad scroll gesture. I don't even remember that the scrollbars are invisible anymore
Does not seem to affect my Firefox setup on Windows but I need to do more testing. I have a scrollwheel on my mouse and still hate the damn tiny scrollbars!
I use the acme text editor https://en.wikipedia.org/wiki/Acme_(text_editor) for work every day. It makes heavy use of mouse chords, so I need 3 real buttons on the mouse, and it's hard to find a mouse with 3 real buttons and a scrollwheel which doesn't get in the way of the buttons. I've got a Kensington Expert Mouse trackball which works pretty well, but at the end of the day an old Logitech PS/2 mouse plugged into a converter is my go-to.
Depends by what you mean by "real buttons" but my first thought was that 99% of gaming mice will have at least 3 buttons and a scrollwheel. Often it's closer to 10 buttons.
> Depends by what you mean by "real buttons" but my first thought was that 99% of gaming mice will have at least 3 buttons and a scrollwheel. Often it's closer to 10 buttons.
I am very interested to learn about your workflow. What language do you program in? How does acme help programming in this language? Do you have a video or a stream I could watch? I'd love to know!
* Select text & middle-click it (or just select with the middle button & release) to execute a program. I just keep a file full of common commands open at all times and fire them off as needed.
* The "acmego" tool automatically formats my Go code & adds imports as needed whenever I save. The "A" tool can find the definition of any function/type/variable I'm looking at and open the source file to an appropriate line. (yes I know these things are available in other editors)
> I need 3 real buttons on the mouse, and it's hard to find a mouse with 3 real buttons and a scrollwheel which doesn't get in the way of the buttons
does a gaming mouse work? I'm currently using a $10 gaming mouse that has 4 buttons and a scroll wheel. Two of them are thumb-buttons that function very well and are not in the way at all.
I also struggled to find a mouse with a decent wheel that you can click without moving it off which is handy in CAD's. Gave up in the end and switched to using thumb button for middle click. But there's an option to get one of 3DConnexion CAD Mouse's if you can swallow the price tag.
May as well call it Tracky McTrackface. Looks like and awesome project but “Ploopy” is such an odd naming choice. Is it a non-English word or have special meaning in the community?
You might like the Logitech Anywhere MX. 5 real buttons and a scroll wheel that toggles between clicky and smooth. Only downside is that it's not bluetooth, it needs a tiny USB dongle.
To be fair, it's usually pretty awkward and feels bad though. It is often very easy to accidentally scroll a bit on the wheel while depressing the third button.
Genuinely curious what you do when you have to navigate a long document or page that doesn't have a clickable table of contents. If you're at the top and you need to get somewhere close to the bottom, do you just sit there and flick the scroll wheel for 5 minutes?
I think you mean hovering to get the widget to appear, going to click it and having it auto-hide as your cursor is on the way, then hover again, repeat 2 more times, then finally be able to click and drag the widget.
I know it's a joke, but I feel some people take this kind of thing seriously. Yes, improving stuff can break other stuff, but that doesn't mean we should never improve anything, it just means the devs (and PMs if applicable, probably not in the Linux world) need to have a feedback pipe coming from users to let them know what the consequences of the changes are.
The Expert Mouse costs a lot, lot more than a simple trackball. And my subjective feeling is that it's actually less ergonomic than the cheaper Logitech I've got.
I cannot use that kind of trackball. It relies on actuation with my thumbs, and it hasn't worked out very well in the ones I tried. I prefer "ambidextrous" ones with the ball in the middle.
There’s also the slightly smaller Deft Pro (https://switchandclick.com/elecom-deft-pro-review/) which I also own and use for travel — it has a superior scroll wheel and therefore may be a superior choice for you.
For me the Huge has a perfect form factor that outweighs all else.
I also prefer a real scroll bar because it's easier to accurately scan through huge files, but I'm honestly confused at the idea of not having a scroll wheel in 2022.
Excluding touch/gesture mice like the Magic Mouse, I don't think I've seen a mouse without a scroll wheel in maybe 15 years. Is it just a hardy relic, or do you have some kind of special design for accessibility?
Edit: Nevermind, sorry I just noticed the other reply that asked the same thing. It's still a very unusual confluence of requirements, but I kinda get it with a track-ball.
Speak for yourself. Firefox on my PinePhone is not pure overlay scrollbars like almost all other mobile platforms, and I certainly appreciate the ability to manipulate the scrollbar to achieve more scrolling with less effort, and to jump to different parts of long documents with it with just a touch rather than potentially multiple swipes.
What if you don't want the same applications with the same interface modalities on different devices? Shouldn't we be much more concerned about data portability than application portability?
You don't really get around that with convergent applications either. That is, unless your idea of convergence is "lowest common denominator for everyone".
Web application interfaces have already been ruined for desktop users by trying to serve both mobile/touch and desktop/mouse. It would be a real shame if other native software followed suit.
It's not at all obvious it can be done well, as the input methods are different, and the UI should match them.
At any rate, the video establishes how it is done poorly. Terrible GNOME UI, lots of empty space, functionality mostly hidden from the user, if not completely inaccessible.
I have to say I just don't like Gnome's design. The shift away from text and towards more and more abstract icons, the "don't theme my app movement", removing features I consider pretty essential like typeahead....
Maybe mobile is where their weird (to me) design choices will finally shine though. Also looking forward to what KDE can accomplish in this space.
The “don’t theme my app” thing just tells me that GNOME/GTK+/Adwaita aren’t built in a way that gracefully handles theming, or that devs building apps with them are doing things like hard coding colors when they should be using dynamic system colors such as those provided by UIColor[0] in UIKit.
Supporting themes imposes an ongoing technical burden across the whole ecosystem. It's not worth it. You don't hear people say "I hate macs because I can't make my title bars purple".
Yep and that’s great, but there are still other legitimate uses for theming. One of mine is cutting down padding to reasonable levels — GNOME is much more usable to me when using a theme like Nordic or Skeuos, both of which do that.
This attitude is why we can no longer have stuff that doesn't only come in "light theme" or "dark theme". I consider this a regression. Let me theme my damn computer the way I want. It's called a Personal computer for a reason.
It is silly that dark mode isn't regarded the same as just switching themes. Forcing its adoption however breaks dependency on non-themable components so its popularity is still a net benefit.
There's a difference between "we'll test and support two color schemes" and "we'll design ui with parametrised colors, shapes and text sizes which can adjust to any change and still be usable". If we settle on bright/dark/colorblind mode selectors that everyone expects to be supported, I'm happy. I've seen themes in the past and there was always a few apps which just can't resize elements in the expected way, or the backgrounds don't tile correctly, or ...
Ok, then don't support it. But don't patronise me. Don't tell me I couldn't possibly wield the power of recolouring a piece of UI without hurting myself, and deny me the chance to even try.
But libadwaita hasn't taken away the ability to try? You can still load custom themes through GTK_THEME and specific CSS through ~/.config/gtk-4.0/gtk.css.
Don't get me wrong, I'm glad to have any measure of control at all. It's just that I'm frustrated that we had infinitely more capable theming system already in place, and it was broken.
I want customizable color schemes and fonts and sizes. It's nice as a user to pick full-on custom themes. Sadly even though Qt is based around theming, I had to turn off theming for semi-customized controls (colored sliders) to make them render correctly on Windows and Linux Breeze/Fusion. And it's more work to verify my app looks good across OSes when QButtonBar and QFormLayout change appearance on different OSes. So finding a good solution is nontrivial.
I'm quite sure you could change system colors willy nilly in OS 8. It was great fun. I miss that part - the feeling of having "your own" system.
Since customization where pretty standard back then, it feels like product managers pushing their "vision" rather than technical difficulties preventing that nowadays.
Kaleidoscope and later on Appearance Manager in Classic Mac OS were so much fun. No OS theming system I’ve encountered since have been as capable as those were.
Ye I wonder what fantastic APIs were actually exposed. I remember some 3rd party screen saver I had. Where like Goofy peeked out of folders and Donald Duck was cleaning up some file mess. I mean, how could you even program that?
I think it was on the real desktop, not some bitmap, but not too sure.
I get what you’re saying but I find GNOME more evocative of iPadOS than macOS. It’s almost exactly what you would get if you tried to create a desktop environment using an iPad as a starting point.
macOS still has several traditional desktop affordances that are eschewed by GNOME, like full menus (not just hamburger junk drawer menus) and customizable toolbars.
I do say that. The light-grey on top of light-grey theme means a lot of times the only way to tell which is the foreground window is by looking for the 3 colored dots.
I feel like partially the movement happened because some themes made the apps unusable and then instead of blaming the theming, users blamed thee app developers instead.
In some cases badly designed themes (like dark gray labels on black backgrounds) are the culprit, but most often it’s a result of the app developers hard coding colors in their UI elements assuming all users will be using a similar theme.
That’s not only bad for custom theme users, it’s bad for accessibility since there’s no way for increased contrast modes to modify the hard coded colors. Apps really just shouldn’t hard code colors.
KDE (or rather Qt) goes even further and still let's you completely change the way interface elements are rendered, which is great because it means you can use the same look across versions if you want to and are not beholden to the latest design fad.
I build bespoke UI elements for iOS apps all the time and building them in such a way that they look and function correctly not only across light/dark and accessibility modes but also future OS versions is not that difficult, and with how they’re built I don’t see them breaking even if iOS took on a radically different appearance. They might not match perfectly but usability will not be impacted.
If this is not reasonably possible with GTK, then it seems pretty clearly like a weakness of how GTK handles themes. Personally, I believe that CSS is ill-suited for the task and is responsible for many of the issues depicted in that blog post.
> not only across light/dark and accessibility modes but also future OS versions
When Apple makes a future OS versions they are expected to avoid breaking apps.
The comparison here would be not to future iOS versions, but to arbitrary jailbreak tweaks that overhaul the look system-wide. You're not ensuring that will look good with your app ;)
GNOME has design zealots similar to Apple, but with more bizarre choices.
Their whole crusade against tray icons and a usable task list have been painful to deal with. Do they just not like multitasking??
It's sad too, because there's a lot of nice UI/UX in there, it's just buried under all sorts of crazy choices. Thankfully, there's extensions to restore some of the missing functionality.
But why discontinue the old method before the new one is ready? This leads to an awkward UX and disinterest by developers, during the time there is no option.
GNOME probably imagined it had enough market power to persuade app developers to change their design. Also GNOME likes to emphasize "distraction-free" computing so the designers probably thought status icons are too distracting for users.
A dedicated tray is a concept tied to windows 95 style UX. I hope the new designs are more about standardizing ways to indicate various statuses and actions of "the app" broadly, without dedicated status icons. For example download progress is still only an Ubuntu Unity protocol that KDE also supports because they can but it's all not freedesktop standard.
It's not just Linux that suffers from outdated tray APIs. It is the same on Windows. To create a status tray icon button, you need to call the Win32 Systray API (the oldest Windows subsystem, forget about using WinUI or UWP). The way apps like Google Drive and Dropbox do their fancier systray popups is that they get the x,y coordinates via the systray API (NOTIFYICONDATA passed to ShellNotifyIconA) and then render a chromeless window at the location with a slide up animation via something like Electron. I don't think the default systray menu can be styled to any reasonable extent.
How about applications that are controlled entirely from their status icon, like dropbox or vpn apps? Fedora, which normally champions GNOME, is beginning to acknowledge that status icons are here to stay whether GNOME designers like them or not: https://pagure.io/fedora-workstation/issue/246
How about desktops that don't have anywhere to put status icons? i.e. what if I don't want to have any panels? Working as a normal window should be an option in all applications.
With "old" method under X11 the icon was just a tiny window the application created that was then embedded in the tray window and you could do basically anything with it. This caused problems with transparency though so for the sake of a prettier desktop (and because this approach would not work with Wayland) we got a more limited D-Bus protocol where you only get an icon and a menu.
Very interesting. The current state of tray icons is one of the most painful aspects of desktop Linux, in my opinion. Where are these discussions happening, and what kinds of plans are in the works?
I still dislike the gnome3 title bar with the icons. As you say, unlabelled mystery meat and hamburger menus.
I'll admit, part of my dislike for the new title bars is probably irrationally rooted in just wanting things to stay like they were on windows 98 when I first became familiar with computers, forever, and never to diverge too much from that. But those unlabelled icons, they really do puzzle and frustrate me. On websites too
Unlabeled icons are terrible. I use Gmail more than any other application outside of dev tools like my editor and my terminal, and I use every single one of the message operations (archive, snooze, add as task, report spam, etc.) at least occasionally. After a month with a new work Gmail account I realized I was still waiting for the tooltip to pop up before clicking the buttons, just to make sure of what I was clicking on. Fortunately, Gmail lets you switch to text buttons. Now when I want to snooze a message, I just click snooze, instead of thinking, "This button is a clock, I bet it's snooze, but hold up, what if it's another time-related operation I'm not thinking of... okay, confirmed with the tooltip, now I can click."
And that's for a button I click several times per week!
I still use the html gmail, that's getting harder to access all the time (and which google now just straight up ignores being set as your default view, and gives you the javascript view anyway unless you manipulate the URL)
The convention for mobile UIs is that tooltips show up upon long pressing the buttons. Unfortunately, sometimes that does nothing, or something else entirely (e.g. start dragging).
> I still dislike the gnome3 title bar with the icons.
It's a key part of touch readiness. There's even a Windows-like theme for Gtk3+ that looks really close to the original, you might like it better than the default look.
Why do we have to suffer it on the desktop though? It’s so damn hard moving windows on gnome without setting something off accidentally. Especially with the shitty touchpad input devices.
My mac laptops aren’t touch screens and they get this usable.
The whole gnome desktop makes me want to stick forks in my eyes.
Yeah, clicking and holding on a header bar button will still allow you to grab the window without firing any action. It's quite handy, especially with a touch pad.
You don't have to target a button at all, that's quite silly. Aim at the window label. Labels have always been connoted as "plain text" with no actions associated, so they're quite intuituve for that purpose.
Of course! But when you're using an application with a fairly busy header bar (like Nautilus or Epiphany, which don't have any labels) it can be useful to just point at the first pixel you come across without having to aim for a blank interval between buttons.
On the other hand (ha) it does not require any aiming. I can super+drag windows into "aero snap" targets in milliseconds because I don't have to spend any time on finding the header bar.
Depends on the user to be honest.
I quite dislike title bars (Especially if fairly bulky.) and so I remove em.
I know they're necessary for people who aren't as apt with computers.
But to me their main purpose has always seemed to be...identifying the programs i use every day and are fairly easily identified regardless.
I love Gnome 3. For me it's the best desktop UI because it forces you to run everything full-screen and use search and keyboard shortcuts instead. (And everything is tailored for this workflow.)
Not even joking. I wish the Windows 95 computer interaction model would just die already.
They could at the very least put labels under or next to the icons.
In regards to touch-readiness: TBH I've had a laptop with a touchscreen, and I never once used the touchscreen on it productively in any way. On a tablet it's a different story of course, but no one is forcing them to do a one-size-fits-all approach. But yeah, my main complaint is really just that stuff isn't labelled. Everything else I can begrudgingly understand somewhat
> They could at the very least put labels under or next to the icons.
On a desktop, you should be able to hover with the pointer and get tooltips. Mobile is more of a challenge, but it's not like text would be any better. You can't fit much text in the typical mobile touch target.
I'm still burnt by the fact that RedHat contributes so much code to Gnome that they basically control it. They made Gnome wholly dependent on systemd and this is how RHEL was able to influence every distro out there, of consequence, to adopt systemd as well. No systemd? Then you'd have to maintain your own patched fork of Gnome.
That aside, Gnome's UI is horrendous and can only be made better by installing tons of poorly supported extensions. It's like a lesser MacOS (and frankly, i despise MacOS's desktop as well).
KDE and XFCE aren't perfect, but as far as MacOS, Gnome, Windows 8.1, 10, and further, and other Linux desktop environments, KDE and XFCE blow them out of the water. Mate, Cinnamon and others just don't have the stability or functionality.
I'm not really enthusiastic about Gnome and KDE trying to bring stuff to mobile. It's been a fool's errand. Here it is, 2022, and they never captured a chunk of the desktop market.
The phone market at one point had Ubuntu (very very briefly), FirefoxOS (even more brief), Blackberry (gone), Android (multiple versions), Windows Phone (gone), and iOS.
All that's really left is iOS and Android. Google is looking to replace Android with an OS that lacks the Linux kernel. So what you got left? Pine phones? It's even more niche and more hobbyist than desktop linux was in 2001.
The year that linux makes any serious inroads into mobile will come just like the "year of the linux desktop" came. Which is never.
So we've ruined a perfectly good desktop environment and poured countless man-hours into KDE and Gnome for mobile and to what end? Why? WHo's going to use it? What's the point? What's there to accomplish?
Beyond some college kid being real proud of his Summer of Code project, nothing of note will materialize from this.
I wonder if people who develop those apps actually use them in real life, or do they simply treat it as yet another software development job. The latter could easily explain the problem: by failing to “scratch one’s own itch”.
I moved from being a Linux zealot during the late 1990's to just use it on the server room, because what I really cared was UNIX actually and ironically all commercial UNIXes have had a better desktop story on having a full development stack story and with exception of macOS all others are practically gone.
Ironically despite all my C remarks, XFCE is one of the best experiences on desktop Linux, followed by KDE.
Just to think that on a past life I did write articles promoting Gtkmm.
I have read through it. I just vehemently disagree that their requests are reasonable.
The only reason why people care so much for their apps' "branding" is being enforced by product management. Absent that pressure, you get a reversion to the Windows ecosystem pre-2005 (more or less), where every user can make their desktop as nice or ugly as they want, and by and large, the sky isn't falling. Because everyone works with the platform and tries to fit into it instead of breaking the mold.
One thing I really hate about electron apps (besides performance in many cases) is the extreme branding they do. Every app looks differently, not fitting in with the rest of OS.
As a user, theming is a powerful feature to make things look somewhat consistent.
Though I use KDE and Qt apps as preference, and very few gnome apps. They tend to cope with this pretty well.
As some who normally uses GNOME, I actually like apps to have distinct visual identities so that they are easy to tell apart at a glance. When using VSCode or Chromium I prefer their native title bars and modal dialogs, which integrate with the rest of their appearance, instead of the grey system-provided widgets.
I can imagine.. But everything about GNOME rubs me the wrong way, so I find it hard to compare. The huuge title bars even when I don't have a touchscreen, everything hidden under a hamburger menu, the lack of configurability..
So for me the comparison against KDE is very different. KDE's tools have pretty sane defaults and can be customised very well.
Who's “product management” in this context? Most of these apps are just made by one person.
Again, this letter isn't about users making their desktop nice or ugly; it's about distros applying stylesheets to apps without checking whether the app remains usable, and leading users to expect that this is the app developer's responsibility.
This is the most misleading part of the entire text on that website, almost as if it was written by a skilled poltician who knows how to lie on your face.
They say that they're not against tinkerers but that's exactly what they've done with libadwaita and libgranite.
Many developers think that the user's systems are their own playground or ad billboard.
They refuse to play nice around theming, user-selected icons, security sandboxes, disabling of tracking functions, providing security updates. Many are careless around the amount of memory or CPU used.
Distributions, instead, are on the side of the end users.
Distributions act as agents of the user precisely to allow you to have more options where otherwise customization would be too much effort or too technical for individual users. Taking existing applications and combining them into a cohesive experience is the entire point of having different distributions.
> ...Changing the default fonts is definitely supported.
Not for the GNOME shell, unless you're editing the relevant CSS files in /usr/share/themes or installing themes that do so. And if you do end up doing that, you get to see issues like this
And I wouldn't be surprised if changing fonts became an unsupported feature in future releases because apparently, it was just a hack and not well supported and didn't really work like themes. Apparently, gnome-tweak-tool is an unsupported tool as well.
The high-contrast mode does not accommodate for all people with colorblindness. I knew a number of people in Libera who were appalled when they updated to GNOME 40 and could no longer theme the shell to be actually visible.
Agreed. Visually, it is... fine, I don't care that much and the iconization of everything is probably just trend chasing. And personally I don't care too much about theming, but either it should be supported, or not.
But it is so dumbed-down now that I find it pointless as a desktop. I try it out every time I rebuild, and become frustrated with how it doesn't do any number of perfectly reasonable things to want from a Linux desktop. Then some random component I don't even care about starts misbehaving enough to be distracting, and I switch back to blackbox.
> Agreed. Visually, it is... fine, I don't care that much and the iconization of everything is probably just trend chasing. And personally I don't care too much about theming, but either it should be supported, or not.
I'd take inability to cope with, at the very least, color palette theming, as suggesting that a program or ecosystem probably has some serious problems with accessibility.
> and the iconization of everything is probably just trend chasing
Icons work better as touch targets due to their uniform shape. So I think the change is driven by ergonomics as well, in a context where touch support is already expected.
Touch is as relevant as 3d screens lol. I remember buying a laptop with a touchscreen back in 2011, there are as many today as there were back then. Tablet usage has dropped to less than single digits and are pretty much a dead form factor except maybe the iPad pro. Etc..
It's cool they have this (mostly) working on mobile, but those gestures are pretty clearly all copied from Android and not a result of KDE Desktop's design decisions.
The first version of Kirigami (the tookit used by plasma mobile) had a very interesting concept around navigation and people hated it. We still have some remnants of this with some floating buttons that are easy to reach for the thumb but also often on top of the content.
I really prefer us to copy a bit the UX of Android/iOS than spending a lot of effort trying to come up with our own UX concept that is not inferior of the one of Android/iOS. We are just an handful of developer and none is paid to work on it.
Please stick to copying the Ux. KDE desktop shines for this very reason that there is no learning curve. First versions should always be heavily inspired by something and later versions can be about innovation.
With UX, copying others should be the default: don't make users learn a completely new set of behaviors that aren't the ones they've been using every day.
It's not even about likability, GNOME UI simply denies users access to functionality. Now, on a mobile, you typically don't have the time/attention/focus to actually scrutinize things much, and you need simple actions to be over-emphasized, so that kind of UI philosophy is tolerable (arguably beneficial); on the desktop it's the opposite.
My favorite thing about Gnome is that I don't have to use it. It's there so that the subsystems get used by normal people and bugs get hammered out and I can do the same thing with a small shell wrapper.
My least favourite thing about GNOME is that it has co-opted GTK and sabotaged it so that even determined developers stand no chance of achieving native look and feel on other platforms and desktop environments. The G in GTK now (de facto, not de jure) stands for GNOME.
(Expressed otherwise: I kind of have to use parts of GNOME because it has infected GTK and it’s much more difficult to avoid GTK than to avoid the rest of GNOME.)
With the advent of libadwaita, GTK really is GNOME toolkit. Most advocates are really deceptive when they talk about this and say GTK4 is agnostic to platforms but I haven't come across a single non-trivial GTK4 app that isn't based on libadwaita. Even LibreOffice is becoming a libadwaita app.
The GUI ecosystem on Linux is mostly dead. I'm trying to switch to CLI and TUI apps for all of my tasks. If they don't exist, I'll try to create them.
I don’t think libadwaita is a problem in the direction you’re saying at all—it’s a comparatively slim layer mostly of additional components that should generally not be all that difficult to make optional if you desire. And you can easily use GTK without it if you want.
Rather, I think the problem is that libadwaita hasn’t gone far enough. The advertised theory is that GTK is agnostic, and libadwaita gets you GNOME HIG stuff, but the fact of the matter is that GTK is still heavily GNOME. Their attitude to overlay scrollbars is a good example (though hardly the only one): they deliberately removed the admittedly-clumsy system-wide configurability that was present in GTK 3 (not sure if themes were able to control it before, but I think not, which was itself a regression from GTK+ 2), and have declared that overlay scrollbars are a feature of GTK 4 and there will be no attempt to comply to system conventions, or any way for users to change the behaviour; individual apps can still control it, but there will be no conventional way of switching this, which de facto means that almost no apps will provide any switch for it, and so users that want real scrollbars or want platform convention compliance are left high and dry. They also deliberately dismantled the module loading technique, which was a way of fixing things GTK made a mess of and allowing improved platform conformance support, including things like global menus (it was admittedly technically unsound, but it worked).
The issue (as I see it) is that libadwaita is GNOME's bartering chip. For years they've been anal-retentive about custom theming, be it their infinite diatribes about how XDG only needs to respect 2 themes, the "Don't Theme My App" disaster or their ongoing attempts to put custom stylesheets further and further away from the user's control. GTK4, libadwaita and Flatpak are their leverage here. Each of these systems, when taken separately, make it difficult to theme your app (though still technically possible). When incorporated though, it becomes outright unreasonable to theme things. This is wholly their fault, and this notion that "they didn't know what they were doing!" makes me roll my eyes. They know exactly what they did, and their behavior has been insanely harmful to the rest of the community.
As a matter of fact, I think the Linux desktop might just be permanently split as a result of their actions now. It's a more extreme version of the old GTK2 vs GTK3 argument, but this time the divide is more extreme. Wayland is borderline unusable on anything but GNOME. GTK4 refuses to integrate with any desktop but GNOME. libadwaita is dividing the development of applications to "GNOME app" and "not GNOME app". Flatpak is a broken olive branch that is in a comical state of neglect (and only integrates well with GNOME anyways).
This segregation has to stop, or it will kill the Linux community along with it. In their attempts to make Linux competitive with Windows and MacOS, the GNOME maintainers have completely quit listening to their users and sabotaged everything that people genuinely liked about Linux.
and having to pull in hundreds of MBs of dependencies to use just one KDE app, say Gwenview, I'd say that platform agnostic GUI apps are either dead or rare. qBittorrent is a good example of such a rare app that works really well across desktop environments and window managers on Linux.
> As a KDE user i have to download hundreds of MBs of dependencies just to use one GNOME app
which is why I later clarified that I think that development of apps like qBittorrent is mostly dead. They work well across all desktop environments and window managers without needing hundreds of dependencies. Everyone apparently decided to fragment the already niche desktop landscape on Linux.
I love that some work is going into UI design, but there are a few things I really dislike in gnome apps. For example using a hamburger menu instead of a regular menu or icons instead of text for buttons.
Combined with the fact that without the top menu bar you can no longer use the Alt-combinations to get to the corresponding menu (e.g. Alt-F for file menu). Motor-memory is hard to reprogram so I'm not a fan of the latest Gnome "usability" choices.
History is back around to repeating itself. I'm an avid Linux user (and even a developer who uses GTK pretty regularly), but the recent developments surrounding GNOME, Flatpak and their related libraries has not made me optimistic for the future of Linux applications.
GTK4 is really bad. It launched with horrible text rendering issues (still unfixed, 10+ months later), broke compatibility with a number of basic features, and then had those features replaced by the GNOME middleware known as libadwaita. libadwaita is in a "functional" release state, but still lacks support for custom stylesheets, basic desktop integration on non-GNOME desktops and has it's own litany of bugs that accompany it. Fair enough for brand-new software, but the state of GTK4 is unacceptable and borderline impossible to use on a daily basis. If you're a developer, things only get worse. Gone are the days of fast app development with gtk::Builder workflows, and now Glade has been thrown by the wayside with no replacement. Talk about a second-class developer experience. And then there's the strange omissions that the GNOME team insists on; some issues are marked as WONTFIX since they can be mitigated with Flatpak. Some features (like appindicators) have been ignored completely because they don't align with the GNOME desktop's vision. The general demeanor of the team has been my-way-or-the-highway, so making suggestions mostly gets you labelled as a troll in their gitlab and sees you forcibly removed if you don't give up and assimilate into their opinion.
Flatpak itself is becoming the new Wayland. With more than 600 open issues on Github and outstanding issues like random data deletion, portal malfunctioning, compositor glitches, security holes and more, it's less like the "one package manager to rule them all" and more like "snap but it doesn't work". It's slow, doubles the dependencies that you store on your system (!!!) and doesn't integrate with your desktop unless you go out of your way to install questionable third party hacks that forward your native stylesheet and XDG options. I'd honestly rather use AppImage if given the option.
The future of app development on Linux is bleaker than ever. Fragmentation is at an all-time-high, and the technology that was supposed to fix it only fanned the flames into an unsalvageable dumpster fire. If you are a Linux developer planning on shipping an app, please stay on GTK2/3 for the sake of your users. I outright refuse to run GTK4, libadwaita or Flatpak on any of my systems. Nothing I've seen recently changes my opinion on that.
> The general demeanor of the team has been my-way-or-the-highway, so making suggestions mostly gets you labelled as a troll in their gitlab and sees you forcibly removed if you don't give up and assimilate into their opinion.
Remember:
> I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.
> It is my hope that you are a GNOME app. Yes this kind of fragmentation is unfortunate. I'm not happy about it either. Anyway, I just wanted to give you a heads up. Wish you the best.
This was a message from a GNOME dev about the transmission torrent client, 11 years ago. I guess they're consistent with themselves over time at least.
The issue about border decorations on Wayland on their gitlab was also bewilderingly infuriating.
Heh, drive by comment saying app functionality will be broken with no clear replacement, from someone who didn't even know a major desktop environment at the time, then proposals from another dev to completely rearchitect the app about 6 years later.
Only if you are hung up on gnome of course. Plenty of alternatives that work out of the box in desktop space and flatapps aren't really needed really as one click with much less issues is possible many gui package managers.
First option for anyone coming from other OS should be kde. Defaults are sane and customizations are easy to do. Frankly I really don't know why all distros provide gnome by default. There are neither helping themselves nor the broader linux desktop community by shipping something that's broken in so many ways.
> I really don't know why all distros provide gnome by default.
As far as I know, GNOME is still the only Linux desktop environment that includes a screen reader, and possibly some other categories of accessibility tools. That's important for distributors who are legally required to provide accessibility options, e.g. because they're selling to the US federal government.
> libadwaita is in a "functional" release state, but still lacks support for custom stylesheets,
Libadwaita is an implementation of GNOME's design, analogous to libgranite in elementary OS. This includes the visual design. GNOME only has one style, Adwaita (which means “the only one”!).
If you don't want to use GNOME's design, you don't want to use libadwaita.
> basic desktop integration on non-GNOME desktops
Libadwaita is the library you use when you're targetting GNOME.
If you want to target something other than GNOME, you don't want to use libadwaita.
Libadwaita isn't trying to be a general-purpose library for making apps that feel integrated on any platform. I don't think it's reasonable to criticise it for not being something it's not trying to be. It's like objecting that a dog doesn't meow :)
> and has it's own litany of bugs that accompany it.
> Libadwaita is the library you use when you're targetting GNOME.
> If you want to target something other than GNOME, you don't want to use libadwaita.
Does GTK4 provide any viable model of development if one doesn't want to target GNOME or elementary? I, for one, haven't seen a non-trivial GTK4 app that doesn't use libadwaita or libgranite and the more I discuss this online, the more I suspect that this is intended but unspoken behavior.
Even LibreOffice has now decided to use libadwaita. Does that mean LibreOffice's GTK version is only intended for GNOME? If yes, GTK4 is basically a toolkit for GNOME masquerading as a general purpose toolkit.
> Does GTK4 provide any viable model of development if one doesn't want to target GNOME or elementary?
It's possible to make apps using GTK3 without libhandy, so I don't see why you couldn't make apps using GTK4 without libadwaita.
Technically, libadwaita is just a bunch of widgets. Apparently it's a very useful bunch of widgets.
> Even LibreOffice has now decided to use libadwaita. Does that mean LibreOffice's GTK version is only intended for GNOME?
I guess so. Either that, or they're intending to use libadwaita in an “off-label” way.
> If yes, GTK4 is basically a toolkit for GNOME masquerading as a general purpose toolkit.
The whole reason libadwaita's widgets are not just part of GTK is so that GTK doesn't have to cater to GNOME, and can be a more general-purpose toolkit. Libadwaita 1.0 was just released last month, so presumably it will take some time for that to come to fruition.
As someone with firsthand experience in this field: it's not worth your time. Getting GTK4 to work in other desktops is a shitshow in the first place (it has horrible rendering issues on x11/Plasma configs), but all of the good stuff like gtk::Builder and connect-closures have been removed, making imperative development an enormous pain in the ass. If you still manage to make an app despite that mess, you'll be left with horrible font rendering issues that can only be fixed with a very specific Flatpak configuration (hope you didn't want to run your own app natively!) and by the time you've got it all figured out you'll probably be looking into Qt.
Please, just use GTK2 or GTK3 if you're planning on making non-GNOME apps. GTK4 is simply not finished yet.
> We've made it through decades without breaking theming, what changed?
According to the GNOME team, application developers were getting bug reports filed against their application about broken interface elements, and GNOME was having bug reports filed for the same. The devs stated it was the fault of the theme being used, and as such it would eliminate a lot of headaches for both if themes were forbidden.
"Independent developers" set out to explain this in more detail. [1] While it is targeted at vendors who created their own themes for branding, it echos the overall sentiment toward theming from GNOME itself.
I'm not talking about a library, I'm more concerned with DEs implementing the library.
Things like swipe with three fingers to switch desktops, swipe up with three fingers to show open windows etc. Why is all that stuff tied to a UI theme?
Swipe to switch desktops is implemented in GNOME Shell and Mutter. GNOME Shell's default CSS style is also called Adwaita, but it in no way affects the availability of gestures.
If Libadwaita optionally extended GTK (based on desktop preferences) so that when Gnome apps are used on other desktops they can fall back to GTK or other inherited UI, that would be great, but at the moment, Libadwaita is a hard dependency (when used), which makes Gnome applications more different (than not using Libadwaita) on other desktops.
I've been a gnome user for well over a decade. What's common to hear from people like you who have a good level of understanding the ecosystem and the community is that Gnome developers consistently make shitty design decisions and refuse to take input from a wider audience.
What is the reason for no group emerging, forking gnome and doing it the right way? I'd actually pay to support such efforts.
> What is the reason for no group emerging, forking gnome and doing it the right way? I'd actually pay to support such efforts.
That's basically what happened with XFCE, MATE, Cinnamon and Budgie, the rest of the userbase is pretty contented with other desktops like Plasma that can fill most of the same gaps.
With that being said, I too would fund a GTK2 or GTK3 fork if I could be promised developers who don't swing their ego around like a sledgehammer and refuse to apologize when things break. The GNOME project is starting to be the albatross of Linux development, and while I'm happy to develop with GTK3 ad-infinitum, I do hope that a fork emerges from someone more capable (and with more free time) than me. Come to think of it, it's kinda crazy how most modern DEs are made just because of how tired people are running the GNOME treadmill.
It’s not forked from Gnome but KDE tends to stay out of your way pretty easily and supports just as much as Gnome (with some Wayland caveats) if not more. In fact KDE community is very responsive and if you participate you will likely experience and benefit from the momentum they have.
I wish I could get any Linux on my Surface Pro 3. That thing heats up to 60c within 5 minutes of turning it on, and then randomly freezes. This is how I learned about the awesome feature Wayland has where you can't reload your session like you can in x11...
You'd need a really big lot of $s to go beyond RedHat/IBM's budget ; you wouldn't hear as many complaints if GNOME wasn't the default DE on so many distros.
That's what XFCE is. (And MATE of course!) Now that they uniformly use Gtk3+, they could even try to achieve better touch readiness than even Gnome itself!
> An example is Flathub, where new applications using the most modern toolkits and UX strategy appear every day, providing "just works" alternatives to complex older FOSS software,, in a boom similar to that seen around 2012 on Apple's Mac App Store.
Damn that’s sad to read - for those unaware, Linux had one of the first app stores ever in about 2002 (Click n Run on Lindows/Linspire).
Also, I remember back in 1996 when quake came out you could buy the shareware CD which came with all of IDs games locked. You called up a number and paid to get an unlock code. Very, very quickly a serial generator started floating around.
Furthermore, the variety of projects that are enabling convergence on their applications is growing at a fast rate, with KDE, GNOME, Nitrux, Elementary and Jingling among others shifting their interest on mobile-ready and touch-friendly applications for the future of Linux.
So, in other words, Linux desktop applications are going the same way as "desktop" applications on Windows and MacOS. I put "desktop" in sarcasm quotes, because so many of these apps are just upscaled mobile apps, which retain the giant buttons and low information density suitable for a 6" touchscreen even when they're scaled up to a 24" monitor.
Yeh that worked out really well for the last two platforms who tried it…
Microsoft produced apps that no one used because they were horrible on all devices. Apple conceded defeat and we have different interfaces on each device class.
The recent "scaling down" of Linux Gtk+ apps also encompasses "diferent interfaces". Look at some of the convergence examples, and you'll see all sorts of widgets merge, move around and disappear behind "alternate" views as window sizes shrink, then come back as the windows enlarge again. It's a fully responsive interface that merges both styles of interaction seamlessly.
A certain $2tn+ company can't manage to pull that off and actually has different interfaces for each platform. We're making some big assumption that responsive interfaces actually work and don't push poor compromises on all users at the end of the day.
This is another UX death march like flat interfaces without cues and mystery meat.
Apple conceded defeat and we have different interfaces on each device class.
Apple hasn't conceded defeat. Every release of MacOS becomes more and more like iOS. Apple keeps releasing tools, such as Catalyst, to make it easier for iOS developers to get their apps to run on MacOS. Apple is very much pursuing convergence between iOS and MacOS, to the latter's detriment.
That's exactly the problem! There's this idea that, if we automate the 80%, developers will do the last 20%, and we'll end up in a land of milk and honey, where mobile apps scale up their information density and rearrange their UIs to suit the high precision pointing devices and large screens that come with desktops and laptops.
In practice that never happens. Developers make their mobile app, use the automated tool to make it into 80% of a desktop app, hit the publish button and proudly advertise, "Hey, look, we have a desktop app now!"
Maybe it's fine for Apple and Google to ruin their desktop UIs like that. Maybe they don't care, or, more likely, they think that catering to the vast majority of users who are on mobile is an acceptable tradeoff for alienating the few of us who still prefer desktops as their primary computing device.
Linux doesn't have to tread the same path but there's no one behind it all waving a big stick when they go off track. Which is why we end up in a fragmented half baked mess every damn time and why I'm sitting here on a mac after 20 years of being promised linux on the desktop
I just run them with unit scaling. The digitizer is accurate enough, especially if you live an OSK window open and stick to keyboard shortcuts. I prefer the extra screen realestate.
I am sure that there will be a successful counter-culture. I do not have Suckless folks in mind or others that are minimalist and Unix philosophy above all. Don't get me wrong - I like most of their software, but I'm too lazy to be a purist. I would love to see more GUIs augmented by command line, but with a bit more GUI and mouse then the latter. I think I'm not alone, but a movement or a desktop environment that unites people thinking in that similar way is not there yet. I'm sure it will come.
This is why we still need html/css for interfaces, so the PWA with wasm still seems to be the best way to distribute an app that works anywhere, or PWA for mobile and electron for desktop with wasm enabling very high performance client features.
I disagree with the whole premise of having a single app for both desktop and mobile. Even if you give developers the tools to make a good app for desktop and mobile, they won't. They'll make the mobile app first, ensure that it runs on desktop, and then dust off their hands and call it a day. To quote the Purism blogpost cited elsewhere in this thread:
Web designers now have toolboxes to design web pages, which they adjust for mobile or desktop in order to get easier readability and use.
Except, web designers don't adjust web pages for mobile or web. They adjust pages for mobile, and then what you end up in a desktop web browser is acres of white space and buttons that are the size of your head.
The way I see it, this is Linux UI framework developers chasing Apple, Microsoft and Google's taillights yet again. Sure, Apple, Google and Microsoft don't care, but that's because they're trillion dollar companies and they have to go where the majority of the customers are. But why does Linux have to go there too? Why can't Linux UI framework developers focus on an under-appreciated niche (desktop "power" users) which are increasingly neglected by the megacorps?
> Except, web designers don't adjust web pages for mobile or web. They adjust pages for mobile, and then what you end up in a desktop web browser is acres of white space and buttons that are the size of your head.
I had to laugh at this.
I am writing a PWA now and this is definitely an issue in "desktop mode".
The thing is though, with giant monitors (I develop on a pair of 4k curved ultra-wides) there is so much room that most non-game apps just don't need all that much space. If you do use it all, it becomes cumbersome to move the mouse all the way to the corners because it is so far away. And even if you did use it, there would still be acres of unused space most likely, white or some other color.
I suppose you could do a true re-write and put multiple mobile screen onto one desktop screen, but that would be a very heavy lift and in the case of a saas app that will largely be used on mobile, it is pretty easy to understand why it never gets done. Bad cost-benefit and it would delay your launch.
Yeah, I agree that it's challenging to fill up a 3840x2160 or an ultrawide 3440x1440 monitor. But I see apps (Gmail being a prime example) that don't even fill up 1920x1080 window.
KDE demos well, but it feels like bug whack-a-mole with each pmOS upgrade. The native browser seems to be missing kwallet integration, and Firefox alternates between working and not; in particular the on screen keyboard hardly ever works with it.
sxmo actually works as advertised, but it's not exactly a mainstream UX. I couldn't figure out how to get it to sleep automatically, so the first time you forget to sleep it your battery dies.
> An example is Flathub, where new applications using the most modern toolkits and UX strategy appear every day, providing "just works" alternatives to complex older FOSS software
I go to Flathub. Click the first app I see. <App not found>
One of the biggest drawbacks to me about Linux is the aesthetic quality. This gives me alot of hope. As the author said this might really well be a turning point.
Although it takes a lot of configuration work ricing my desktop is how I got into Linux and I've always found that the aesthetic improvements seen in popular OSs to be similar to the popular aesthetics trends in the Linux community (although they obviously take a lot from other OSs too)
I just switched back to XFCE on my desktop, because panel launchers cannot be properly configured in a simple way. Too bad usability made all the good looks useless. And I feel a renewed assuredness, that XFCE is the most productive DE for me. I had it configured in 10 minutes and it does everything I want in the way I want. Also XFCE these days can also look nicely.
Still, usability (and that includes being able to configure things easily) is king and I cannot stand it, if I cannot configure annoyances away.
Panels are indeed a gigantic pain in the ass to configure. It is possible, but I feel like I have to go to three completely unrelated places each time I want to. And I can never remember which place is the one to go to.
How does XFCE do with high-DPI displays? My only other complaint with Cinnamon is that the window controls are a tad small. It's been a long time since I used XFCE.
Oh, I don't know the answer to that question. I have 3 full HD screens and have not looked for anything more, as it seems completely sufficient to me. Maybe someone else knows. However, I do know, that you can configure icon sizes and font sizes.
I'm on Kubuntu (so KDE), been using it for over 6 months now. I am the kind of person that loves setting up the desktop and all the apps just like I want, so it has been perfect for me, although the defaults are pretty solid as well. The default Breeze theme also is really pretty, I went through all kinds of themes but eventually settled with Breeze due to how good it looks.
I'm not, but I would love to some day. I fucking hate my android phone (and the iphone is just as terrible, in slightly different and often the same ways). Thank god for the people tinkering on pinephones and purism phones, paving the way for something less awful, with control in the hands of the user
We're not there yet, but we won't ever be unless people put effort into it. The linux desktop used to suck, too
To me, phone os is an easy way to get to apps, switch between apps, and handle notifications. It appears to be something else for you. What is an ideal phone for you, and how would Linux help achieve that experience?
Not the person you're replying to, but I have the same issue. The phone OS is indeed a way to get to apps for me. And the problem is that the "alternative" phone OSes don't have access to apps that I've woven into my day-to-day-life: banking apps, contactless payments, video streaming, music streaming, etc.
None of these are available on platforms other than iOS or Android, unfortunately. Some of them have web experiences, but they're terrible on mobile when compared to their app.
I, too, would love to run a mobile-optimized Linux desktop on my phone, but it's not about the desktop, it's about the apps and functionality it gives me access to. So I'm stuck with Android for the time being.
What would be really cool is if these alt mobile OSes could perfectly emulate Android to the point that Google's SafetyNet would believe that everything is a-ok. Not sure if that's even technically possible, but could help bridge the gap and allow alternative OSes to gain some market share among people who aren't willing to give up many of their usual mobile apps.
> What is an ideal phone for you, and how would Linux help achieve that experience?
The main bits for me are privacy and control. I refuse to use an iPhone because I viscerally hate Apple's stranglehold over the platform. I very reluctantly use Android, hating that Google is always watching. A fully-open mobile OS where I get to choose what runs on it, how it runs, and what access it gets would solve both of those problems.
I don't like the ridiculous number of settings you have to tweak to stop google from spying on you, 4 settings levels deep somewhere. I don't like that google made phone manufacturers take the "disable location" button out of the quick menu. I don't like the restrictive policies of the app store that is downright prudish, and how every app on the app store is just laden with crap and ads, and often also spies on you (i do use f-droid to circumvent most of that when possible). I don't like how you literally cannot control your phones update behaviour. I don't like how after a couple years, the phone will stop being updated and you'll have to buy a new one or just accept that your phone has security holes that will never be fixed. If you're using a modern phone os, you are fundamentally not in control of the device, and it will make sure at various points to remind you of this.
That's pretty much my use-case too. I want my laptop, but smaller :)
Primarily, I want software I can trust, because I trust that the developers' motives are aligned with my own: a useful tool that I'm in control of.
In my experience, most Free software fits that bill; whereas most proprietary software seems more interested in persuading me to buy something or sign up for something that I don't want. (Most, not all; I can think of counterexamples.)
Bluntly, Free software is usually much less full of skeevy bullshit.
> Bluntly, Free software is usually much less full of skeevy bullshit.
Yes and it's amazing how much smaller, faster and battery-efficient it can be without all the marketing and tracking crap.
Most apps on F-Droid are a few MB as opposed to tens of MBs for the play store ones. Most are well written and efficient. The quality of these has really increased the last couple of years.
Until I can plug my phone into a keyboard/mouse/monitor and have a powerful workstation I don't care that much about linux desktop apps being on my phone. My phone is backup/on-the-road browser, messaging applicance, and a phone 95% of the time.
DeX is pretty useful yes. A bit compromised though by Samsung's latest phones skimping out on the memory side, the S22 has the same amount that the S10 came with 3 years ago. DeX really needs lots of RAM as you'll typically have multiple apps open unlike on a phone screen. Once you run out browser tabs will start refreshing as soon as they so much as lose focus...
Really 12GB or even 16 would be much better for DeX. But you can only get 12 now on the ultra and not everyone likes massive phones.. I don't anyway.
Even if 8GB may be enough now it won't be as apps get bigger. It was nice in the beginning on my S8 but the last years I had it I hardly used DeX anymore as the experience became too slow and the refreshing too annoying. For example, just moving away from a form in a browser tab to copy something from my password manager would result in the browser tab refreshing upon return and the form inputs lost..
I don't particularly care about that either, I just want something I have actual real control over, that's updateable indefinitely, and doesn't shove crap in my face or spy on me
I have a Pinephone. I tried, in earnest, to use it as a daily driver; but the software stack was hideously unperformant and the camera was just too awful.
I have young kids; I need to take pictures quickly on occasion. I couldn't rely on the phone to do that, not by a long shot, and so it remains a pointless curiousity that I purchased.
With my recent kernel patches megapixels starts in 2s, which is less than my android phone. It wasn't too long ago the camera app ran at 2 fps and it's now at 60.
I feel like a lot of people are criticizing the PinePhone from the perspective of a product, instead of the labour of love that it really is. Things are constantly improving, but it's not many of us that are spending our free time to do so.
To be fair, the Pinephone store very clearly states that this is a beta device intended for experience linux developers/early adopters only. It’s not meant to be a daily driver yet.
It's not Beta. At the time I purchased it, it wasn't even Alpha. Beta, as a game developer, implies to me that there's a few outstanding show-stoppers but on the whole the product is safe to show to eager end-consumers who are willing to tolerate some rough edges. The PinePhone isn't even that, yet; I couldn't conscientiously hand it to a non-techy and ask them for feedback because I'm not even sure it would reliably respond to their touch input, let alone do anything else.
Well, I don't disagree with that, my point was just that you're arguing semantics regarding the word beta, because their marketing is very clear about what it is (and I'd also argue that beta for hardware is a different standard than for games, but I guess now I'm arguing semantics)
Do you think even a developer will want to use something that falls apart in their hands like wet sawdust as a daily driver? As a developer, hell no. I'll give Linux phones a couple more years before I try that.
Yes, but if it's to address the needs of a real user and not a spherical user in a vacuum, the phone has to be able to handle some rudimentary functionality in the meantime so developers can dogfood what they made. Few developers will carry two phones all the time.
> Beta, as a game developer, implies to me that there's a few outstanding show-stoppers but on the whole the product is safe to show to eager end-consumers who are willing to tolerate some rough edges.
I don't know what games you have worked on but as a user that description seems to match what is called "final patch" by the games industry.
Considering that video games are usually released unfinished; if you're saying it doesn't even meet the dismal quality standards of video game development, wrt Beta quality, then I agree with you.
If Pine64 didn't include hardware that wasn't fully software supported at any arbitrary point in time then the PinePhone as a whole wouldn't exist in the first place.
The thing with the cameras is there's hardly anyone putting effort into them - on average around ~1 person is working on the entire camera stack in their free time (there's a number of people, but none spend their whole time on the cameras). So it's honestly pretty amazing how far we've already come.
Seconded. It's been several years of development time and I still think I'd get better pictures with one of those cameras that saved pictures on floppy disks.
I've bought two Pinephones and I hope things go well but man, I install Mobian and wonder what exactly their long term plan is... it runs like an absolute dog, worse than a $30 Android prepaid phone. The only way to get reasonable performance has been to use sxmo, which is ok for me but not the experience normal people want.
Note that while it's already possible to get really good looking photos out of L5 camera, there's still quite a lot of software work left to do for it to work in an effortless point-and-shoot fashion. It will come, just be aware it's not there yet.
(Note that kop316, who has the second comment there complaining about lack of MMS support, went on to implement MMS support themselves by writing mmsd-tng. Many distros added it recently and it supposedly should work with Phosh's Chatty and on SXMO.)
Yep, I wrote most of the support in for Chatty myself as well. Chatty works pretty well with MMS, and I have been using a Pinephone/Librem 5 full time for almost 2 months now.
A bunch of people are. If you compare the efforts of communities of volunteers against the investments in google/apple phones you can already call FOSS phones a big success.
This board has a real hate-boner for the PinePhone for some reason. Any phone that isn't 100% as capable as a flagship iOS or Android gets defined as "not ready to be a daily driver", because people think their definition of "daily driver" is some universal constant that everyone abides by. The rest of us who happily use it as a daily driver apparently don't exist in their worldview.
Already in this subthread there's "We're not there yet", "I couldn't conscientiously hand it to a non-techy", "It's nowhere near ready to be used as a phone outside of tinkering", "something that falls apart in their hands like wet sawdust", ...
I do. I run Fluxbox on PostMarketOS. I use dino with jmp.chat for mms. I use emacs diary+git for calendar. I have some custom power management service I wrote shortly after getting the phone so it gets long battery life. My bank and brokerage both have decent web sites.
I'll never go back to a non-Linux phone, I'd rather not have a phone at all than tolerate the older mobile OSes.
Create a new virtual machine and set the window size to 720x1440 with 2x scaling (or just 360x720) which is what the Pinephone uses. Everything else is the same as desktop Linux, just compiled for ARM.
1. Buy a device, https://wiki.postmarketos.org/wiki/Devices#Main . I suggest the PinePhone if you want something with decent power management in the next few months, or PinePhone Pro if you're willing to wait a few months for decent power management.
I mean...that's why I said "more or less". There are of course differences, but a lot of app development can be done on a linux system and a cross compiler.
Signal and power management make or break a phone. My Nokia N900 makes for an excellent Linux phone (I have been unironically using it as my daily driver for communication, and the battery has been replaced recently too), but what really kills it is that its battery life is very unpredictable.
Sometimes it lasts 36h on a single charge when in standby, and sometimes a fraction of that. I cannot trust it to last me a whole day without a charger.
Other older phones that I tried last year (ranging from very old Nokia's to Blackberries with 3G) all had issues with call quality and even with random signal loss. I couldn't reliably stay connected with my family, which frustrated everyone.
Your application/mobile OS likely uses mobile data in some fashion, definitely uses up some CPU cycles (in foreground or background), may trigger high-powered modes in the cell radio through its usage patterns, or might miss incoming messages entirely. Testing on real untethered hardware, even as a final check, is needed to see that what you built isn't a frustrating paperweight that cannot fulfill the function of a phone.
Fltk is stack-based (no heap allocation) and parents own their children. When a parent window goes out of scope, poof, memory cleaned up.
Fltk is also easy to use. In C and C++ land there’s fltk-config utility that will automagically set compiler and linker flags etc.
There’s a lovely fltk book that the rust crate links to in its extensive documentation.
There are plenty of even lower resource options like littleVGL, which only needs a drawing routine.
Gtkmm3 with C++ works well for me. I'm looking now on Gtk(mm)4 and Libadwaita. They improved the docs recently but the C++ documentation is kind of separated.
Rise in cross platform frameworks would be a positive trend.
When I am writing a flutter application, I often run on desktop directly and resize to mobile shape. That works good enough unless I am writing a mobile-specific feature. This probably means most flutter apps can run on other linux based phones as well.
Cross platform frameworks have already risen in Electron. Every application I use at work runs on Linux. VS Code, Slack, Zoom, Postman, and others I can't think of are all Electron.
And they all perform fine. The speed difference between JS and native is meaningless in 99% of cases given how fast modern CPUs are. RAM usage is similar. Everyone complains about it, but I've got 32 GB and I don't get above 8GB usage when using these apps.
Probably good for there to be competition in the cross-platform space. Maybe Electron is a little overly-bashed, but it's best when it's not the only game in town.
Strange that electron isn't mentioned here. I develop a desktop application that targets macos, windows and linux, so it is a full-fledged linux app — but without such an effective cross-platform toolkit I don't think we would have resources to support Linux at all.
Convergence? How many times do we have to go through this? No one wants convergence. It's the worst of both worlds. Keep the hobbled UI and gimped network workarounds on mobile where they belong.
Easy to say that when you have a full-time dev team vs a solo open source developer. Getting it out the door is step 1, a team can always build purely mobile, tablet, and TV versions if they want, in addition to your desktop (and possible server apps).
I don't think Purism gets enough credit in this article. They've dumped a lot of time, money, and effort into developing Phosh and other tools that make this possible.
I have an Manjaro linux based laptop that I got a few months ago after my mac died. It was supposed to be temporary until I could get my hands on one of the new m1 pro's but I ended up liking the experience. It's fast. The hardware doesn't throttle. And most things I need run fine on it. In case you are wondering, I got myself a Samsung Galaxy book with 16GB i5 and SSD which was discounted very nicely during the pre-christmas sales to about 700EUR. Bargain and excellent value for money.
Don't get me wrong, Linux is still a massive PITA to set up properly. Forget about using it without ever seeing a command line. But, I can deal with that and I've googled my way to success when it let me down a few times to get things going. It's kind of depressing though that things like keyboard, sound, gpus, desktop sharing, touchpads, etc. just don't work in a sane way out of the box. I had issues with all of those with things either not working or just being mis-configured.
One thing that helped a lot is that a lot of proprietary applications can be installed via snap and games can be installed via Steam. Some OSS ones as well. I installed slack, signal, vs code and a few other things that way. And where that failed me, I was able to find some community AUR packages for things like webex and Chrome. Flatpak seems like it should do similar things to snap but mostly packages seem easier to find for snap. I don't really care about the philosophical differences between both. I'll use what works. A problem with both is hardware support. E.g. the Darktable snap is completely pointless because it lacks opencl support; the flatpak one has the same issue. I had to wait for the official package to be updated by Manjaro when they did their yearly release at Christmas. That took a few weeks after Arch updated upstream within a day or so. I have a GPU, why would I not want to use it? This is just flat out moronic.
I actually had some fun playing some Steam games that long stopped working in the mac version of steam (64 bit only) via proton. Very easy to setup and install. And to my surprise the Intel xe gpu actually isn't that bad. And of course GPUs work fine with Steam.
It seems software distribution is no longer blocked on distribution gate keepers not keeping packages up to date. I don't like to read about an update and then have to wait for it for six months while some non affiliated developers second guess all the testing and fixing that already happened upstream by the people that actually created the software.
IMHO modern distributions should push out most end user applications to snap, flatpak, or whatever and focus only on the stuff that absolutely can't work via those. That simplifies things for both developers, distribution maintainers, and end users. Distributions aren't really adding any value here (the opposite I would argue). That will rapidly achieve what three decades of dozens of linux distributions reinventing the light over and over again never achieved: a homogeneous market for distributing end user Linux applications (OSS and closed source). Given that a lot of those can be cross compiled to mac, windows, chrome os, android, and whatever, that is not a small market either. We are already starting to see some of that. A lot of SAAS software actually is based on things like Electron and creating a snap for that is not that hard. You'd be a fool not to. Even if it's less than 1 percent of your users, it's still worth doing.
Until there is as “simple” to use an app like Preview on the Mac, most of these new generation apps are garbage.
I’ve just switched to Ubuntu on a workstation I have lying around. And man, is it hard to use for just normal everyday use.
Yes, it has the basics covered, but like many others my job has a lot of simple image manipulation related stuff.
Convert pdf to png. Assemble multiple images into a pdf. Quickly share with someone else over chat. Normal productivity stuff.
Take a simple thing like screen capture - you have to remember to save the screen that you captured otherwise it just sits there doing nothing in the screen capture app.
The thing that saves most Linux desktops for office productivity workers — is Firefox and Chrome. Otherwise, outside of programmers and highly specific use cases, hardly anyone would use a Linux desktop.
And that’s kudos to the fact that so much of what we do these days is in a browser.
But if you look at the small pieces of software to do everyday things - they are awful.
Dropbox barely works in a sustainable way.
I have to keep pulling out my laptop every now and then to do simple office productivity things.
Yeah yeah, I know that Apple is a trillion dollar company that had a room full of people just working on the screen capture feature alone.
And yeah, I use Linux every day for programming. But Brah, all the little widgets and do-da’s need some serious polishing.
Trying my best not to sound like a raving Linux zealot, but what you see as normal productivity stuff I may not have done... ever.
Converting a PDF to a png? Why? Maybe IrfanView could do that, it's what I've been using on Windows for any conversion since ACDSee went out of fashion...
I've never seen a GUI tool that works as flawlessly as pdftk. Yes, it's CLI, but it works better than anything I ever encountered.
Screenshots? You just need to find the right app, I'm not happy with the windows thing (I've been using Greenshot for a while and it's on par with whatever I use on Linux).
But yeah, my comparison is only Windows, I've never owned a mac. And maybe I'm on the completely other end of the spectrum in my perception of what "normal tasks" are.
Have you never needed to annotate/sign a PDF? On Mac OS just open Preview (the sane default for PDFs), use the annotate tools. There's even a built-in UI for "scanning" a signature via the front-facing camera, the software automatically cuts out the background so you have a signature to drop on the page. Save and the PDF is signed. Trying to do this on Linux requires moving a mountain.
In KDE:
- Double Click PDF, Opens it in PDF viewer "Okular"
- Select "Stamp" Annotation Tool
- Draw region to place stamp
- View stamp properties and click to select image source
- Select SVG file I always use that has my signature that I created using my wacom tablet.
- Adjust placement if needed
- Save file
Takes all of ~15 seconds. Don't see how that equates to moving mountains.
15 seconds and a wacom tablet. The killer part of the preview.app is that it uses the front facing camera to capture a signature, quite well if i might add.
I've only ever done this with my own signature (so, a one-time process), of which I have a scan and my workflow hasn't changed for 20 years, just the tools. as the other reply said, just inserting an image into a PDF is not a problem, and I still don't understand the use case of the camera. But in this case maybe I've had my signature available for longer than phones with cameras exist contributes to the fact?
I'm not saying you're wrong, but maybe all the office work I've done in my life is simply different.
That’s because you’re not a “normal” office productivity user or even online creator working with just normal customers needing normal docs, files, and normal staff that you need to share normal stuff with.
I can't claim you are wrong... But I struggle with versions of those on my Mac on a regular basis, as well. Screen capture, in particular, is hilariously fickle for me. I finally got it so that it puts the image in my clipboard. Which is great, until I try to remember how to get it directly to a file. Because, I can't remember where that setting is anymore.
And I have no idea how to make a pdf on this computer. Combine multiple images? I don't even know why I would do that. Much less how.
My favorite battle recently was just trying to shutdown the machine without it starting right back up. Pretty sure that isn't possible if you have external monitor and keyboard hooked up. Which took me several shutdowns to realize.
Most of these are fairly discoverable and have been consistent for decades:
Shut down: Apple Menu > Shut Down (since ~2001)
Print to PDF: File > Print... > PDF > Save as PDF (since ~2001); some apps have an File > Export... menu item as well
Combine multiple images: Photoshop (or image editing app of your choice, e.g. Pixelmator, Acorn, Affinity, Krita, etc.; since ~1990)
Screen shot: command-shift-3 (entire screen) or command-shift-4 (selection/window), (since 1990s; earlier for print screen; Mojave or later for command-shift-5); discoverable/configurable via System Preferences > Keyboard > Shortcuts > Screenshots; modern macOS also pops up a thumbnail you can click on
I also clearly knew how to do a screenshot. But once you have set it to go to clipboard, command shift 4 will silently do that from now on. And I am not at all clear on how I would discover to change that.
And the pdf claim was with preview, not another app.
Worse, though, I could write a very similar rebuttal for any computer in this vein. If you know how things work, discovering is not hard.
Yes, I suspect you may be correct in suspecting your USB dongle or keyboard from sending a power-on signal. I ran into a similar confounding problem where bluetooth keyboards and trackpads in a drawer were being pressed/activated and constantly waking my laptop up when it was connected to an external monitor!
I don't fully understand the task you were trying to complete, but Preview is not an image editor so I don't think it can do what Photoshop (or other image editors) can do. It can however combine multiple PDFs into a single document by drag-and-drop, and this is documented in Preview > Help.
I was trying to say something that is perhaps a bit more nuanced than "it's easy once you know how to do it" or even "it's easy to find once you know where to look" – specifically, the Mac UI was originally intended to be fairly discoverable by exploration (and relatively clearly documented), and although some of this has been lost due to iOS-ification, much of it still is:
1. Menu items such as Shut Down are easily discoverable (but in your case it didn't work, perhaps due to an external keyboard turning the system on.)
2. Export to PDF is very discoverable, but isn't universal; print to PDF is discoverable, and is documented in macOS Help, but is perhaps more subtle than it should be because it's in the Print... dialog. I suspect its location there is due to historical and implementation reasons rather than testing users who are unfamiliar with the system. "Preview" after all is named as a "print preview" application rather than a "PDF viewer" app.
3. Screenshots are discoverable by searching for "screenshot" in System Preferences or macOS Help. If you forget the keyboard shortcut it's in a fairly logical place: Keyboard > Shortcuts.
4. On macOS, the Help menu is contextual based on the current active application. Overall system help, titled "macOS Help", is located in the Finder's Help menu. This is perhaps a bit subtle for Windows users who may not know what the Finder is (it's like Windows' File Explorer) and might not realize that the Help menu is contextual. There are "macOS Help" entries for each of these tasks, but you need to know to look in "macOS Help".
While much of the macOS UI is still fairly logical, discoverable, documented, and consistent over many releases, that doesn't mean that a Windows (or Ubuntu) user will instantly know how to use it without learning some important design differences, or vice-versa. The good news is that once you learn them they're fairly consistent across the system.
An interesting point that you might be suggesting which I definitely agree with is that even after 40+ years of development, traditional desktop GUIs can still be greatly improved even without changing their fundamental design.
> My favorite battle recently was just trying to shutdown the machine without it starting right back up. Pretty sure that isn't possible if you have external monitor and keyboard hooked up.
Apple Menu -> Shutdown. Make sure you don't have the "restart" checkbox ticked.
Works fine on my MBP with external monitor and keyboard
Shift+Command+5 gives you the full screenshot experience, and let’s you define where to put it (Desktop, clipboard, etc.) Once you select a location, it will be the default for next time.
Preview let’s you create a PDF pretty easily?
No idea what’s going on with your restart issue tho.
Not clear how to use preview to make a pdf with multiple images. I'm guessing that is something that is easy if you have to do it often? I'd probably reach for html or word. Probably word, first.
The easiest way is to open your PDF document in Preview, turn on View > Thumbnails (if it isn't on already) and drag and drop your image document into the thumbnail pane.
You can combine entire PDF documents this way, either dragging them from a Finder window or dragging the title bar icon from an open document.
You can also drag and drop thumbnails between open PDF documents in Preview, and you can create a new document from the clipboard if needed using File > New from Clipboard. (Note if you want to drag other pages into it you will need to save it as a PDF first.)
They do by default, but you can make it start sending to clipboard. I find that a bit more convenient for many uses. Evidently, if I use the 5 version instead of 4, it gives you the option again. Not shockingly, I typically use 4...
> Take a simple thing like screen capture - you have to remember to save the screen that you captured otherwise it just sits there doing nothing in the screen capture app.
idk with KDE this seems to work ? I hit screen capture and spectacle shows up and saves it to images.
Can confirm this works on Plasma. There's also Flameshot[1], which is cross platform, that works really well and has pretty much every feature you could ask for in a screenshot app.
> Convert pdf to png. Assemble multiple images into a pdf
not want to sound harsh, but imgemagick could do that 15 years ago.
I use OpenOffice Draw nowadays, but despite the fact that PDFs have become a joke of a file format, Linux is the best to handle them by far, unless someone thinks that Acrobat is anywhere near to being good (or Preview for that matter)
The issue is not the lack of good tools on Linux, just with the ones shipped with the major distros and DEs.
Quality and simple tools do exist if you look for them:
- Image viewer: feh
- Screen capture: scrot
- Dropbox: Syncthing
- Converters: Pandoc, ImageMagick
- PDF viewer: zathura
- Media player: mpv
etc.
Granted, some of them are CLI only (though they might have GUI wrappers), but desktop users with productivity as the main goal should learn to use and not fear the terminal, instead of settling for whatever their popular brand of distro decided to package for them.
I've had problems with scrot and drawing selections, so I've been using maim for a while, otherwise: yes, exactly my kit - but for IM's convert I have to search for the syntax every damn time, it really sucks.
Funny you mention that. I just got a Mac and I spent 30 minutes trying to figure out how to save a screenshot from the screenshot menu only to rage quit out of frustration. 2 days later I found out I have 20 screenshots from all the failed attempts saved on my desktop!
Nothing about the UI telling me how or where these things were saved. It confused me coming from Ubuntu a lot :)
For an opposing view, for productivity stuff, I really don't like the simple mac apps approach. I regularly open preview expecting it allow some simple changes, but end up disappointed and either do it via gimp or imagemagick. It's similar to Windows experience where people try to release simple apps like a tool for preview, tool for resizing, tool for optimizing compression, tool for merging images/pages, etc.
It's too much hassle when two slightly more advanced tools can cover all of those usecases.
And don't get me started on mac's screenshots which are saved in 12h time in the name, so your 1pm screenshot is before your 11am screenshot and there's no configuration option for it.
Funny that you mention resizing (Preview > Tools > Adjust size) and optimizing compression (Preview > Export > JPEG > compression slider), both tasks that Preview can do out of the box. For advanced edits I use Pixelmator Pro which has a UI that is actually usable compared to the decades-old cluster fuck that is the GIMP UI.
Sorry, I should've used a different word - you can't "expand" the image - i.e. make the size larger and keep the picture in a specific place, so that there's more space for annotation on a side. (or I'm missing the option?)
> Preview > Export > JPEG > compression slider
That's recompressing (losing the quality in the process) not optimizing compression. You can't update the compression settings on a png for example.
Yeah yeah, we know Linux isn't in the perfect state for Apple die hards. This article isn't about how nice it is to use Linux and how everyone should switch, it's about the advances the UI frameworks and hardware companies have successfully made to better cater to UI DE focused crowds.
I don't want to annotate an image with a CLI, and neither do you. And a CLI is the worst UI possible for a visual task like editing an image. Apple figured this out 38 years ago with MacPaint.
Maybe not a single image, for some ephemeral task I guess, I was more just responding to the gp:
>Convert pdf to png. Assemble multiple images into a pdf. Quickly share with someone else over chat. Normal productivity stuff.
But I don't really know what to say: I very much do prefer the cli! Even if it takes some trial and error, finding the right script that does exactly what you want gives you a reproducible and concise record of your alterations, so if you are in a position where you need to make, say, 100 images with similar annotations, possibly from a csv file or something, you can just do it! Also, it's lightweight, it's a comprehensible process, you know exactly what you are doing, rather than in some alienated userspace where you can never be sure.
I won't argue anyone "wants to", but I know what I want I think!
Pinta [1] is a lightweight MS Paint type program with broad support and a BSD license. It just works.
but it's not the car's fault if people don't want to use keys to start them up.
anyway, there's a huge amount of GUI software to handle PDFs in Linux, I will say that Linux gives you the most options, either as free software and close source ones.
Yes, then I just think for now they are better of with one of the other two. I think its great what progress is happening on the GUI front, but I won't argue with gp that some things are a little sketchy.
But for those who do have the patience and understanding for the shell and man pages, well they can become more powerful than the other Oses combined!
That's how I feel about it as well. My every day machine is Linux but I also have to use a Macbook and a Windows machine and of the three I absolutely hate using the macbook. It feels like very design choice in MacOS was purposely chosen to annoy the hell out of me.
Regarding the screenshots, maybe using the PrtSc key is more suitable for you? PrtSc alone saves the whole screen, Alt + PrtScr the active window. You'll find the screenshot as a png file in your "Pictures" folder.
Note that ImageMagick isn't always the best tool, since ImageMagick always reconverts the image, often with lower quality. Often it's useful to have the image to go in as is, or use a loseless resizing. I use img2pdf for that with great results.
I almost can't tell if you are being sarcastic or not!
It's gotta on some level be at least apples/oranges right? You describe a process with more steps, that involves launching a GUI app to do one thing. Maybe its more intuitive, but I would argue the interface makes the user, not the other way around.
I've been a long time linux desktop user, recently switched over to macOS after getting fed up from not being able to do many basic "productivity" related tasks, without having to open a terminal, search for a package on google, fiddle with some config, do a rain dance, etc...
Skimming through just the blog post and some of the comments on this thread gives me a bit of a flashback thinking of all of the headaches I've endured __trying__ to get Linux to work for simple stuff like document management, PDF markup, synced notes, calendars, display scaling, general performance things, etc.. This was fun and interesting at first, but after a while there were diminishing returns. Believe me, I really wanted it to work, I love Linux (as a server). It hit me at some point that life is brief, and technology should probably be making my life easier, not more difficult.. So I switched to macOS.
That aside, it is really important for progress on this front so that we don't have a total monopoly, and kudos to anyone working in the space. Fighting the good fight.
I did feel like you and did the same as you, however I noticed I am just fighting a different fight in macOS than Linux it is not all that better you still have to fight the system to make it work for you
- Convoluted first setup , you need x-code command line tools for even say git.
- Docker doesn’t work completely for all builds and still needs a Linux vm to run
- your servers are not usually arm64 not everything works as it would locally
- node < 12 projects need Rosetta hacks which are just as annoying to get to work. Similarly support for older versions runtimes /apps /libraries limited
- Applications like Dropbox have(or had) limited or no support and only slowly adding them
- I have to still setup basic coreutils and dozen other gnu basics which either are not there or very old versions from 80s
- Procfs and other standard Linux goodies you are used to are not there .
- you have to keep in mind BSD isms and context switch. Flag order matters in BSD /Mac world rm /dir -rf won’t work but will in Linux.
- Homebrew is not too bad as package manager but compared to Linux world (apt , Pacman, yum or emerge ) it is pretty limited in features and options
I've had the exact opposite experience. When I started using Linux the UI was a crutch, but as I learned, the command-line became much more compelling because it was substantially more powerful- it's infinitely easier to add features via flags and params than it is to integrate in a GUI. I pretty much live in the command-line now and I've never been more productive.
All of my calendar/doc/notes needs are in the cloud, so I'm dependent on a browser there. I don't have any display issues and general performance is better than Windows 10. I mean, just being able to run BTRFS is a game changer in reliability. All that said, I still love MacOS and use it for my work laptop, but Windows is just a hot mess at the moment and not something I want to subject myself to.
btrfs has come a long, long way. At this point the only major remaining problem is the parity raid implementation, so most people just run it on top of mdraid. btrfs native striped and mirrored raid are stable at this point.
In my subjective experience, I've been using it for the last 6 years and have not had a fault thus far.
I'm giving it a shot once again (fourth time I believe?) but even Jim Salters article from last year really highlight the short comings. He does focus on RAID like you mention, however the tooling in general in full of papercuts as he shows and IME. https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
I've been running it on my primary nvme drive for the past year and have had no issues and performance has been surprisingly good. Raid for a high-end nvme drive is a bit out of my budget.
They are different paradigms. The command is a power tool, suited for expert users (vs intermediates and beginners)
The stance is also different of the command line. As someone who also does creative work, the command line is simply not a tool I can use. “Paint Logo” is not a command :)
Making Linux a diverse tool for different stances and operations would be a great help for adoption.
I'm fine with GUI tools, I use them too. I just like the CLI for lots of things that I do. I write lots of scripts for various tasks, set them up as startup scripts or cron jobs and I'm done. GUIs are terrible for automation.
From installing custom ROM on their phones, to deciding which JavaScript router to use along with other 99 packages to run a blog.
We’ve all been there.
But sometimes the time comes, where you just want to be as productive as possible or focus on other things.
And that’s when things like Ruby on Rails or iPhone start look interesting. They just work, and let you focus on creating value, rather than feeding your inner pedantic tinkerer.
Does the IPhone just work though? My wife has one and I always find it a pain to deal with. Simple things like playing videos often don't work with VLC (never had this problem with Android) so I have to use Handbrake to convert it to a format that the Iphone will accept. Same thing with audiobooks, MP3 versions don't work I have to convert them to M4B for some reason.
My sense is that it "just works" if and only if you've completely bought into the Apple ecosystem. If you want to back up your photos onto iCloud, Apple has made it easy. If you want to periodically back up your photos onto an external hard drive, Apple shrugs and says that you should manually copy them over.
I really wish/hope there is a big push to attract creatives for projects. I am 100% sure “tinker to the end of time” mentality hurts adoption as a general use OS.
Tried to donate some time to some projects, but devs usually just shrug or don’t like if you come with UX suggestions. Hopefully that is changing, really enjoyed the article.
The Linux world has two competing ideals: "So easy my grandparents can use it" and "Learning the terminal will make you a better person". Anyone who tries to make things too simple (PCLinuxOS) is derided and criticized by Popular Linux YouTube Channel, Reddit, etc. Anyone who tries to make things too technical (Arch) is ignored by Popular Linux YouTube Channel, Reddit, etc. So only those distros that flounder somewhere in the middle get popular. Ideally, the Linux desktop world would just split in half, so that there can be a clean separation between these two ideals. People who want "Easux is so easy my grandparents can use it" won't be bothered that Hardux is hard to use. People who want "Learning the Hardux terminal will make you a better person" won't be annoyed that Easux is easy to use.
I don't think they're competing ideals at all. What is needed is a configurable system with easy defaults, just like setting nano as the default editor but allowing me to change it to vim.
Maybe in theory they aren't competing, but in practice they definitely are. Remember, open-source is made by whoever shows up and contributes. If everyone who shows up is either a hardcore Linux expert, or someone who want to make Linux easier for the masses, then who will integrate the two goals? Open-source isn't a corporation, where there top-down leadership. It's a bottom-up ad-hoc collaboration.
When I was a younger engineer I loved Ubuntu because I got to feel like a hacker that was making my custom working environment.
But these days I’m just irritated by how much it takes to do _primitive_ things.
I spent 30 mins today just getting my Outlook calendar to display in Ubuntu. I had to use Stack Overflow to learn of a package I had to install. No error messages. The calendar just remained blank until I installed it. Then I had to sync, have the app crash, sync again, and reboot.
I then turned on notifications so I’d get calendar reminders. Had to manually turn off 50 other app notifications. And even with some app notifications turned off I still got notifications (like for every single slack message).
It’s awful.
I think there will always be responses of, “X distro sucks. Use Y instead.” And I’m done taking them at face value. Every distro I’ve tried feels the same kind of bad UX, just usually a different set of badness.
Free is free. Nobody should feel bad about this reality. A lot of hard work has been put into these things. But that doesn’t mean we should pretend that it’s good.
I have very limited experience with Linux but every time I try to install something, I find that I lack some dependency and then wind up trying to build from source. What could fix these types of issues? Why does most software just install effortlessly on Mac OS? Is there something that Apple does that could be mimicked in Linux? I may be naive, but seems like a legit question.
There is a simple thing they do that we could mimick (and some have started). macOS and Windows ditched (or never used) the concept of widely using dynamic libraries and dependencies.
Apple and Microsoft build SDKs that you compile against, and for the most part those are the only dynamic libraries that you use. Between point releases the ABI is compatible so you can do thing like security updates without recompiling applications. Everything else is bundled inside or distributed along side the application and is the responsibility of the app developer.
There are a few attempts at doing this on Linux - Flatpack, Snap, and AppImage.
I would argue dynamic linking in itself is still very important, in the sense that if some nasty security vulnerability is discovered in an important core package (OpenSSL or glibc or something), a patch can be pushed out without requiring downstream applications to be recompiled.
To be honest, I don't think most developers have a robust mechanism of tracking vulnerabilities in the projects they directly depend on, let alone the dependencies of dependencies.
> I have very limited experience with Linux but every time I try to install something, I find that I lack some dependency and then wind up trying to build from source. What could fix these types of issues?
There's a number of solutions, none of them (even Apple's own) are really all that ideal. Pretty much all of your Mac apps are statically linked, which is why you download a large 300mb DMG or .app file that lugs along all of it's dependencies with it when you're getting a program. This has a few advantages (it's arguably safer, you can expect most software to "just work", etc) but it also has some disadvantages (uses more memory, lots of redundancy and "wasted" space with every download, kinda obfuscates directory structure, etc).
Honestly, there is no right answer here. Linux has tried doing a similar thing with Flatpak, but it's oftentimes more trouble than it's worth. Linux desktop software is supposed to be run as a local user without sandboxing; there's very little you can do to change that without re-architecturing the entire program to work that way too.
> Why does most software just install effortlessly on Mac OS?
Wait until you try Brew or Macports. The main reason why I genuinely cannot use MacOS on a regular basis is because of it's lack of a proper package manager, and moreover it's container support and general virtualization is unbelievably bad. If you manage to install Docker you're a hero, but if you manage to get it working properly? That would be news to me. Here on Linux it's just a "sudo pacman -S docker" away, and I don't have to lift a finger afterwards for configuration. Sometimes there are perks to running the same software you deploy to.
At the end of the day, it really depends on how you want to use your computer. I do SRE stuff for a living and desktop Linux is a godsend for that workload. Would I recommend it to a family member though? Not in a hundred years. Linux is still a server operating system first, and a desktop OS second. For me, that makes more sense than buying a Macbook and then using it to SSH into a remote server to do all my work.
A 300MB statically linked app is a million times better UX than the nonsense and user abuse committed to save a little bit of disk space. Absolutely optimizing for the wrong things.
I’m curious which distro you were using. I was forced to switch to Linux as a desktop server because of a HW failure that prevented Windows from booting.
And I have found it a breeze to use it as my primary desktop (it’s not a laptop though).
These apps look very nice, I am happy to see this movement. But this is HN so ... allow me to go a bit off topic and complain.
Why is is so freaking hard to install an app on Linux (Ubuntu)? There's nothing in the software center, and when I find an app I want I am just pointed to a .tar.gz or something. I want a file I can double-click and end up with a launchable icon representing that app in my dock later. I would also like to be able to update that app easily in the future. I have yet to have this experience with an app I wanted despite using Ubuntu for years.
This is why I have given up and just started using Windows with WSL. Then I can have all the command-line tools I like and also a sane app installation experience.
> Why is is so freaking hard to install an app on Linux (Ubuntu)? There's nothing in the software center
If I may also be opinionated… :)
IMO Ubuntu is not very good at curating their repo and presenting it in their Software centre.
GNOME Software is designed to only show graphical desktop apps that include enough metadata. Ubuntu modifies their version of Software to also show non-graphical apps, (including anything packaged as a Snap).
Fedora doesn't make this modification and as a result, Software has less stuff, but a greater wheat to chaff ratio.
Fedora's repos are almost as full of stuff as Ubuntu's, and that's still available through the command line for those who want it; but the more-prominent user experience is less frustrating.
Ubuntu is catering for IoT developers who want to use technical Snaps easily, which is fair enough, but not my use-case. Fedora is catering for a more general-purpose workstation OS, which is my use-case.
> I want a file I can double-click and end up with a launchable icon representing that app in my dock later. I would also like to be able to update that app easily in the future.
A .flatpakref file and GNOME Software does that. This works on pretty much every distro except Ubuntu :) because Ubuntu's modified version of Software doesn't include flatpak support.
In Fedora, I can open a .flatpakref file, which opens Software showing the app's details; I click Install; I have a launcher in the app grid. Software updates the app automatically in the background (unless I switch that off in its preferences).
I'm not saying that Ubuntu is bad here! I'm saying it's coffee; Fedora is tea; I prefer tea, and maybe you would too :)
Do you know how to use apt? [0] It sounds like you're trying to install software the windows way (download from a website and run).
Some software is distributed as source only, but it's super rare for anything remotely popular to not be packaged (although you might have to add a PPA).
outdated packages are the problem of the distro, not of the tool.
the whole reason I went from windows -> linux was because I could just type in what I want, rather than having to go looking around for dumb things on sites that no longer exist.
That installs a binary tool I can run at the command line. Which is great for a lot of things. It's not great for a web browser or a calculator.
I want an app. I want it to have an icon I can click on and a button to close it. I don't want logs in my terminal or zombie processes and I don't want to have to remember the name/path of a binary.
> > what's wrong with the ol' "sudo apt install foo"
> That installs a binary tool I can run at the command line. […] It's not great for a web browser or a calculator.
You're wrong about that. A package manager installs any type of software, the user interface of the software (command-line or GUI) is irrelevant. For example, chromium and kcalc: `apt install chromium kcalc`
> That installs a binary tool I can run at the command line
No, that install an application in general. You choose to run it from the command line. If you want to just turn your terminal into the application, `exec firefox`. Most window managers provide a way to run an application standalone via some shortcut. On i3 it is Win+D for example.
`apt` can install everything you can find in the graphical Software Center and more, and with the exact same results (like icons to click on).
If it's not available in `apt` repositories there's a pretty good chance you can install it with flatpak, which does roughly the same but is distro-independent. Graphical non-free software like Skype is easy to install with flatpak and "just works" in my experience.
What apps are you having to do this with? I've yet to have an app that I couldn't either get through apt or as an AppImage which definitely has that experience of double click and go when you have AppImageLauncher installed.
AppImage does seem promising although I tried it the other day for Electrum (bitcoin wallet) and it was a mess. I was not able to double-click to launch and once I closed the app I was never able to launch it again. Maybe I'll give it another try?
I use Windows/MacOS/Linux(Ubuntu) on a regular base.
As a ordinary end user, I feel
1. Windows software are usually good at product function design.
2. Mac has a better enforcement on overall UX. The visual across different software (from different vendors) are much consistent.
3. Linux desktop is unfortunately still missing above 2 points.
Some Linux distro provides really good visual, but it only applies to its built–in programs. If you'd like to switch to the external programs, the system visual might be fragmented.
I really hope in this new wave people could make some consensus on the visual of Linux desktop.
That's really too bad, IMO Linux and FOSS desktops really shine in the subjective-fit zone, not this consensus area.
Once you start having to please..._waves hand at group of people_...first the fun goes out the window, and then you're playing to an entrenched userbase who are bringing most of their expectations from their subjective past experiences anyway.
Personally when I started using desktop Linux purely for me, and not "as someone who speaks for a professional userbase" I was able to finally appreciate it and become more of the OS-native power-user that my Windows & Mac experiences wouldn't let me be when I tried to force them along on the ride.
The problem with your line of reasoning is that Linux is not an OS. It's a broad ecosystem of components that get assembled into distributions. I have used the word ecosystem deliberately, because it's very similar to any of its biological counterparts.
Things evolve in a pretty organic way. The advantage of this is the lack of a central authority and much more resilience. It's a bit like the Internet. But obviously, there's some room for improvement in terms of user experience.
Ideally, I think this should happen through some loose standards and RFCs, pretty much like it occurred for the Internet.
With that said, the overall user experience is very good if you stick to a pure GNOME desktop. KDE and Xfce are also pretty good. Personally, I prefer running just X and three applications (Firefox, Emacs and XTerm). This way simpler, and there's almost no common UX at all. Just three very different platforms with very well known conventions (hypertext, Emacs applications and text, respectively).
> Some Linux distro provides really good visual, but it only applies to its built–in programs. If you'd like to switch to the external programs, the system visual might be fragmented.
I've noticed that this has improved considerably when using KDE; on both Slackware and openSUSE, KDE and non-KDE applications both seem to look and work equivalently great. There are of course some applications I use that don't match the overall system's look and feel (Steam, Ardour, and SolveSpace all come to mind), but they're squarely in the minority at this point.
Agreed, KDE is great. I like Kubuntu and KDE Neon. A little bit frustrated when I have to use a Gtk application; it's sometimes not working well in a KDE environment.
I tried kubuntu but it felt a bit wonky with some broken stuff, etc
KDE neon i never tried but looking into it heard it doesn't have a lot of users behind it and it's mostly a bleeding edge testing ground.
My best experience so far has been manjaro KDE.
The defaults seem fine and work. Pacman is so nice.
The AUR, snaps, flatpaks, appimages... Tick some checkboxes and they're all there.
I don't feel troubled trying to find software anymore.
My GTK and QT apps look fairly consistent by picking matching themes for both.
- Touchpad gestures through various efforts: https://linuxtouchpad.org
- Gnome: libAdwaita: https://blogs.gnome.org/alexm/2021/12/31/libadwaita-1-0/
- Core workflows getting better first-class approaches rather than being another app to install: (e.g. screenshots & screenrecording: https://www.youtube.com/watch?v=ewC1Zc-5qPQ&t=2s )
- Visual improvements proposed to larger complex apps like libreoffice: https://mobile.twitter.com/ChristianOhrfan/status/1472015987...
I wouldn't recommend it to everyone but it'd definitely interesting to see as someone who came from being a fairly invested mac user - I track personal workflows between OSes here: https://docs.google.com/spreadsheets/d/148zTJUwfVv9xfDcpSoH3...