- Joined
- Jan 5, 2015
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
As the resident GNOME user I have to correct you. Image thumbnails were added in GNOME 44.GNOME still doesn’t have image thumbnails in the file picker, because that would entail writing an API to use something very slightly more demanding to handle the actual file picking instead of the barebones and impractical file picker GTK gives them.
That’s the file browser, not the file picker. The file picker is the one you get when you click “Open File” in for example GIMP.As the resident GNOME user I have to correct you. Image thumbnails were added in GNOME 44.
View attachment 5270802
That’s the file browser, not the file picker. The file picker is the one you get when you click “Open File” in for example GIMP.
Do AppImages support dynamic linking against system libraries? If not, that's one good reason to not support them.How come appimages aren't more popular?
I enjoy using a package manager for my core packages, but if I just wanna mess around with an emulator or whatever for an evening I'd like to just have the GNU+Linux equivalent of a portable .exe.
Appimages are sandboxed, distro-agnostic, and in my experience just work. Despite this, devs would rather include flatpak installers than appimages in their releases.
Why is this the case?
Fair points. The skepticism of anything packaged outside the repos is definitely healthy (although even experienced users will clone wacky git repos without necessarily auditing the source themselves).Do AppImages support dynamic linking against system libraries? If not, that's one good reason to not support them.
More subjectively, people may be worried that an influx of less skilled users relying on AppImages will cause package managers to become less used. Eventually you will just get the same problems you have on Windows, where people just download random .exes and fuck up their computer.
Speaking from a Debian perspective, making a quick and dirty package for your own private use isn't that hard.
At least you would still have the convenience of easy uninstalling via the package manager if necessary. Building things from source is the Debian Way™I guess I could learn how to make my own, although that kind of negates the convenience and I might as well just build directly from source at that point (considering I'd have to repeat the process for every update).
Oh. Fair enough, then.just getting an update dialog and clicking accept to get everything up to date is nice enough to sacrifice a couple hundred MB of disk space (instead of updating it every time I perform a system update).
That’s the file browser, not the file picker. The file picker is the one you get when you click “Open File” in for example GIMP.
The GTK4 native file picker does have thumbnails. GIMP 2.10 does not use the GTK native file picker.View attachment 5270870
It's so close but so far.
If I'm not mistaken, Cinnamon at first was a Gnome fork but with continual mods and changes, I think the Mint team scrapped the Gnome base and made it a standalone DE where the only link to Gnome is that it's built from GTK.
Gnome has spawned multiple forks, including Cinnamon, Budgie, pantheon, and Cosmic. That alone adds to the confusion when recommending a distro to people new to Linux.
Yeah at this point Cinnamon is its own thing. I wonder how hard it would be to convince Canonical to use it as the default DE in Ubuntu?If I'm not mistaken, Cinnamon at first was a Gnome fork but with continual mods and changes, I think the Mint team scrapped the Gnome base and made it a standalone DE where the only link to Gnome is that it's built from GTK.
Maybe I should make a case to Canonical to switch to Cinnamon after all? I just wanted to create a shitstorm that would get things done but maybe there's merit after all.
At the bare least i could argue that GNOME is directly responsible for multiple ports, which has resulted in development work and time lost by being split up into multiple projects when maintainers could be working together.
...sorry, I was getting the feeling that I was getting too repetitive.I somehow see even more corporate control over GNOME after this, and who knows what other projects carrying GNOME assets would be subject to after this, it feels like we're witnessing a schism between community and corporate that is going to cause a disruption in the desktop space, if not medium-term.
EDIT: The hell?
I really like arch's aur system. I've got a somewhat elaborate personal project that might require a few packages and aurs have been a godsend for automated testing and deployment.Speaking from a Debian perspective, making a quick and dirty package for your own private use isn't that hard.
The cura 3d printer slicer is my goto appimage use case. Every couple of months I get a wild hair up my ass to 3d print something so I re-download cura. My settings are stored in ~/.local so I don't lose anything but I'm still using an up-to-date version.convenience of having software that I only use once in a blue moon remain completely outside my package manager is just really appealing to me.
The writing's been on the wall for a while. Red Hat and SuSE are both pushing towards an immutable OS using containers for as much as they can since that hands off package maintenance to upstream. Canonical will probably follow suit.I somehow see even more corporate control over GNOME after this, and who knows what other projects carrying GNOME assets would be subject to after this, it feels like we're witnessing a schism between community and corporate that is going to cause a disruption in the desktop space, if not medium-term.