A new wave of Linux applications
tuxphones.com
tuxphones.com
- 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...
I'm very excited to see what the Pinephone Pro brings as a platform to build towards in this regard. I'm already eyeing shipping some apps on Flathub!
I hope the React Native => Flathub pipeline gets built out, similar to what Ubuntu is doing with Flutter => Snap. Exciting times!
I still use it for servers as everything I use is available in apt anyway. But some desktop packages are only in snaps now.
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).
I know QT is a bit more of a pain to do from Rust, but I wanna say that's possible too... though nowhere near as evident as gtk-rs.
QML still has only rudimentary support for AOT compilation. Both the old qmlcompiler and the new qmlsc compiler are commercial-only: https://www.qt.io/blog/the-new-qtquick-compiler-technology . LGPL users only get the interpreter.
Widgets is still the 'Real Qt'. Some very modern, responsive-layout desktop apps like Telegram are written entirely with Widgets.
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.
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.
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.
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).
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.
If no one has yet wrapped this into a Rust crate, someone should…
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.
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.
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.
Hope you'll try it out! (It's also available on Nightly).
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.
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.
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.
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).
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.
https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotti...
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.)
> People commenting on MacOS UX often forget that people creating Mac GUI applications aren't magically better at doing UX than Linux users.
I say that as someone who dremels their phone and earbuds to make them easier to use, yet still prefers a Debian desktop.
yet??? clearly this should be "so"
The ability to dremel your OS is exactly the thing that Apple stops you doing, and why those of us who run Linux, run Linux.
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.
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 :)
Ok. So after QT, gtk, Xforms, wxWidgets, Xt, Motif etc. it is another attempt.
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 parses your C++ headers to generate helpful metadata used for runtime reflection and slot-and-signals. All the generated code is C++.
The latest versions of CMake support moc out of the box, so developers hardly notice the moc step.
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.
"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.
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
`gammastep` is a good tool to change colour temperature at sundown. Works on wayland.
`darkman` allows handling dark mode transitions (it's a bit more technical).
Many trackwheels on are also slow at of you want to flick many pages down.
I rely mostly in keyboard.
This is why the Apple Magic Mouse is so great - it's essentially a phone surface instead of physical buttons.
Here's a few key points:
* 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)
This one has 20 buttons (including 3 big ones and a scrollwheel): https://www.logitechg.com/en-us/products/gaming-mice/g600-mm...
> This one has 20 buttons (including 3 big ones and a scrollwheel): https://www.logitechg.com/en-us/products/gaming-mice/g600-mm... I really like this mouse https://natec-zone.com/press/euphonie I really appreciate vertical form factor. It's one the cheap side, but it's good for my hands.
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.
https://www.logitech.com/en-us/eol/mx-anywhere-2s-mouse.910-...
Middle Click -> Scroll on the web
Page Up/Page down everywhere else
https://www.logitech.com/en-us/products/mice/mx-ergo-wireles...
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.
On mac I use steermouse to map the buttons.
I promise to stop being a trackball pusher now.
1. go to about:config
2. find widget.non-native-theme.scrollbar.size.override
3. Change to some pixel value (I have mine set at 26).
voila!
I do not understand why the default is so thin. Really bucks the trend of every UI element being touch-screen large nowadays!
My preferred informational / programming layout is browser on left, terminal on right.
And in any multi-window layout, any window not aligned with the right-hand display border remains difficult to target.
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.
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.
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.
It ... doesn't work for any Linux desktop, most especially those using Focus Follows Mouse (certainly for strict, often for lazy) policy.
Though that's useful to know.
Though I'm using click-to-focus, not focus-follows-mouse, so YMMV.
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.
For scroll/touch users, the scrollbar has become an indicator only, and not so much a tool for scrolling, to show where on the document the window is.
Swiping is a pain if you need to jump up and down on larger pages.
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.
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.
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.
You feel every click, and it is translated to aproximately a three line scroll in the document.
It is a very discrete signal, instead of a continuous signal.
Touchpads have this right, the scroll is very smooth, and you can scroll by tiny amounts if you want.
In a way, it is a limitation of the 25+ years old technology. Why it has not been updated to something smoother is a mystery to me.
In an ideal world, you'd be able to choose from a variety of programs, to optimize for your usecase, all while maintaining data portability/sync.
Convergence is a practical choice to allow contributions to be shared by desktop and phone users.
https://amosbbatto.wordpress.com/2020/08/05/advantages-of-ph... discusses this.
If you use the same app on your phone and computer the data is almost certainly portable between 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.
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.
[0]: https://developer.apple.com/documentation/uikit/uicolor/ui_e...
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.
Which is why I really like KDE.
- Requiring apps not to use custom colors alone won’t fix it. Any bespoke UI element an app includes is at risk of breakage when a custom theme redefines the entire world. https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...
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.
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 ;)
But people seem to deliberately obscure why the Gnome devs are doing this and instead accuse them of being lazy and/or dictators etc.
Additionally, see my other comment about accessibility, which is also negatively impacted by hardcoded UI appearances.
Since customization where pretty standard back then, it feels like product managers pushing their "vision" rather than technical difficulties preventing that nowadays.
I think it was on the real desktop, not some bitmap, but not too sure.
I wish Gnome folks did not keep on copying it more and more. I see why it's easier to do, but KDE somehow manages.
(And if one thinks that Apple UX design can't go wrong, remember Macbooks from a couple of years ago.)
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'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
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.
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
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.
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.
I'm not sure, I've never run into this? The headerbar itself, with its labeling text, works just fine as a mouse/touch target.
Not even joking. I wish the Windows 95 computer interaction model would just die already.
And that's for a button I click several times per week!
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.
Thank you for working on KDE!
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.
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.
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.
Especially true for users with partial visual impairments, but also for other users that want to have a consistent style on their desktops or phones.
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.
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.
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.
So for me the comparison against KDE is very different. KDE's tools have pretty sane defaults and can be customised very well.
They say that they're not against tinkerers but that's exactly what they've done with libadwaita and libgranite.
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.
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
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2331
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.
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.
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.
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.
https://extensions.gnome.org/extension/1160/dash-to-panel/
https://extensions.gnome.org/extension/2890/tray-icons-reloa...
These two fix those weird design decisions and make GNOME a pretty good desktop.
Is there a similar reason GNOME doesn't have a convenient task list?
(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.)
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.
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).
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.
Qt says hi.
Yeah, Qt feels better to use compared to GTK but with bugs like these
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-...
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.
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 would like a proper menubar so I know what the accelerators are without having to move from keyboard to the mouse. It's so slow.
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.
Dead dove, do not eat.
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.
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.
What is the reason for no group emerging, forking gnome and doing it the right way? I'd actually pay to support such efforts.
https://github.com/linux-surface/linux-surface/wiki/Supporte...
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.
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.
Where is this from?
Nice.
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.
Now, that is always a fair criticism :)
Why do those things have to be tightly coupled all of a sudden? We've made it through decades without breaking theming, what changed?
If you just don't want the ui design pattern just use the gesture, it's already there waiting for you to make something with it.
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.
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.
A blog post from a dev as well. [2]
[1] https://stopthemingmy.app/ [2] https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...
> 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.
Please, just use GTK2 or GTK3 if you're planning on making non-GNOME apps. GTK4 is simply not finished yet.
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.
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.
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.
If this is the future, I hate 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.
https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
This is another UX death march like flat interfaces without cues and mystery meat.
I think is pretty clear that they work. Look at responsive web pages.
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.
Apple want you to get 80% of the way there, then do the last 20% of tailoring it to the device.
There isn't some magic unicorn toolkit which can do that last 20%.
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.
But why does Linux have to tread that same path?
It doesn't, which is the beauty of open source. If enough people value this as much as you clearly do, there will always be options out there.
And, if there aren't enough people then you always have the (less practical, but still doable) option of rolling your own.
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?
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.
Not for discoverability or visual things.
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.
I go to Flathub. Click the first app I see. <App not found>
https://flathub.org/apps/details/io.mrarm.mcpelauncher
``` App Not Found
No app with the ID io.mrarm.mcpelauncher was found on Flathub. Try searching for the app using the search bar above. ```
Still, usability (and that includes being able to configure things easily) is king and I cannot stand it, if I cannot configure annoyances away.
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.
And I'm using a Pinephone as a daily driver, too.
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.
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.
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.
Did I use it to tinker with mobile Linux? Sure.
Did I find success using it as a phone? No. It's nowhere near ready to be used as a phone outside of tinkering.
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.
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.
I only turned on my Android phone once since December, and that was to factory reset it since I wasn't using it.
We're not there yet, but we won't ever be unless people put effort into it. The linux desktop used to suck, too
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.
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.
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.
https://en.wikipedia.org/wiki/Samsung_DeX
https://www.slashgear.com/samsung-linux-on-dex-is-dead-here-...
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..
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", ...
So much for the "hacker" news...
What a strange thing to say. It's hugely popular on HN.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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.
Phones are battery operated. Performance per watt is mission critical.
Linux phone development is more or less the same as linux development, just with a computer that has a smaller screen and a modem.
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.
It's a UI Framework being used to make the basic OS apps in a fully scalable form. They're currently used in Plasma Mobile.
2. Find good programs on https://linmobapps.frama.io/
3. Figure out what functionality you're missing. Contribute improvements.
Keep in touch with the community at https://linmob.net/
Fltk. There’s a lovely rust crate rs-fltk too.
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.
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.
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.
[1]: https://github.com/duilib/duilib (apparently only documented in Chinese)
Also, flutter memory consumption is often 1/3 or 1/4 of the equivalent electron app, which is significant.
https://apps.kde.org/kalendar/
Do they share any libraries, or is it just coincidence that the UX converges?
This reads like it was written in non-english and then inexpertly translated.
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.
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.
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.
Shift + CMD + 3/4/5 = Screenshot goes to desktop
CTRL + Shift + CMD + 3/4/5 = Screenshot to clipboard
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.
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.)
Apple Menu -> Shutdown. Make sure you don't have the "restart" checkbox ticked.
Works fine on my MBP with external monitor and keyboard
I can try to reproduce later. This was maddening when I was getting ready for a vacation recently. Machine just wouldn't stay off.
Mayhap it is the USB dongle I have that does power and monitor/keyboard?
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.
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.
Re: make a .pdf, just about every print dialogue has had a "print to PDF" for as long as I've been using OS X and now MacOS.
Edit: also, I bet doing an rclone mount of your Dropbox will be pretty seamless and stable, havent tested this personally though [2].
If you don't like the command line interfaces, then yeah you are probably better off with a Mac.
It seems out of whack to complain about linux without investing a wee bit of time with cli.
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!
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.
Hell Acrobat is gold on WineHQ!
>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.
idk with KDE this seems to work ? I hit screen capture and spectacle shows up and saves it to images.
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.
scrot -a $(slop -f '%x,%y,%w,%h')
I can use Ubuntu, for instance, perfectly fine for web-dev. It's great.
But in the end, I'm just fighting it.
The UI/UX on todays Ubuntu and apps isn't as good as macOS was 10 years ago!
And yes, I know there are other Distros and I can customise KDE and Gnome and so on. But they are all offer a very shallow user experience.
I wish the Linux GUI and App landscape looked better!
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.
Takes all of ~15 seconds. Don't see how that equates to moving mountains.
I'm not saying you're wrong, but maybe all the office work I've done in my life is simply different.
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)
convert bla.pdf bla.png
convert *.png output.pdfIt'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.
What the hell is “Contact Sheet” and why should I have to care about this jargon?
> And man, is it hard to use for just normal everyday use.
This is how I see macOS. I've used it at work for 3 years now, and it still gets in my way every day.
I accept that some people like it, but it's very much not for me. (I suppose I “think differently” from Apple's designers.)
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.
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.
Nothing about the UI telling me how or where these things were saved. It confused me coming from Ubuntu a lot :)
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.
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.
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.
Isn't that basically what's happening already?
ChromeOS and Android Linuces on the one side, GNU/Linux (sorry Stallman haters) on the other...
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.
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.
In the modern era I think saying no to dynamic linking is the right move.
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.
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.
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.
In my subjective experience, I've been using it for the last 6 years and have not had a fault thus far.
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.
- 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
And I have found it a breeze to use it as my primary desktop (it’s not a laptop though).
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.
tar -xzvf app.tar.gz
cat app/README
cp app/app /usr/local/bin
make
make install
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.
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.
sudo apt install firefox
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.
> 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`
• https://packages.ubuntu.com/chromium # web browser
• https://packages.ubuntu.com/kcalc # calculator
> I want an app. I want it to have an icon I can click on and a button to close it.
You got it.
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.
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).
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 :)
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.
Consensus over the whole scope of open source?? That's never going to happen.
It's not that hard, I believe.
This is exactly the number 1 challenge for Linux Desktops: hard to coordinate with each party, then we end up hundreds of different distros.
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.
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.
I love it so far.
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.
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).
Yes, exactly users have to stick to one single environment. But when you want to use Gtk application on KDE, then ...