Live data from Hacker News

A new wave of Linux applications

tuxphones.com

381–390 of 584 posts

Re: A new wave of Linux applications

#381

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.

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.)

Re: A new wave of Linux applications

#382

Earlier quoted context omitted.

Status icons were built on old and fractured technologies. They are coming back. Designs and technical discussions are happening right now.

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.

Re: A new wave of Linux applications

#383
post #5

That's cool and all, but who is actually out here using a linux phone?

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.

Re: A new wave of Linux applications

#384

Earlier quoted context omitted.

> Ideally, the Linux desktop world would just split in half, so that there can be a clean separation between these two ideals. Isn't that basically what's happening already? ChromeOS and Android Linuces on the one side, GNU/Linux (sorry Stallman haters) on the other...

ChromeOS and Android don't run on regular desktop or laptop PCs, at least not without a heroic amount of hacking and configuration.

ChromeOS is heading that way: https://news.ycombinator.com/item?id=30350860

Re: A new wave of Linux applications

#385
post #28

Earlier quoted context omitted.

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.

A touchscreen is probably needed for this. Human fingers are huge and you need to design for that in mind.

GTK (and presumably KDE as well) supports touch emulation.

Re: A new wave of Linux applications

#386
post #279

Earlier quoted context omitted.

Excellent links - thank you so much for the resources. 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 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.

Me too. The app startup times in particular make it a pain. And the pollution of the mount table and worse integration an annoyance.

I still use it for servers as everything I use is available in apt anyway. But some desktop packages are only in snaps now.

Re: A new wave of Linux applications

#387
post #129

Earlier quoted context omitted.

> I do not understand why the default is so thin. 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.

For mouse too, actually. I grew up with scroll wheel mice so I literally never had a reason to use a scrollbar to scroll.

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.

Re: A new wave of Linux applications

#388
post #36

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.

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.

Re: A new wave of Linux applications

#389
post #129
post #64

Earlier quoted context omitted.

I found a solution for Firfox on Ubuntu MATE: 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!

> I do not understand why the default is so thin. 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.

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.

Re: A new wave of Linux applications

#390

Earlier quoted context omitted.

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. https://extensions.gnome.or…

Status icons were built on old and fractured technologies. They are coming back. Designs and technical discussions are happening right now.

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.
Post reply on HN