Earlier quoted context omitted.
Ever used npm?
No, and how is that even relevant?
>So why should I trust them less than my distribution?
Just use google -> npm malware
Is there any future for the GTK-based Desktop Environments?
131–140 of 142 posts
Re: Is there any future for the GTK-based Desktop Environments?
#132Earlier quoted context omitted.
OpenSUSE doesn’t have a default. SUSE uses and supports GNOME.
According to their own page KDE is the default desktop: https://en.opensuse.org/KDE > Default Desktop > Plasma Desktop from KDE is the default workspace on openSUSE.
Strangely enough, from their desktop FAQ: https://en.opensuse.org/openSUSE:Desktop_FAQ
> openSUSE installer provides three officially supported desktop options. There is no default choice
Coming at this from another angle, their installer isn't super opinionated. The KDE radio button is at the top of the list on the desktop selection page.
Does that make it the default choice? I guess it does by some definition.
Re: Is there any future for the GTK-based Desktop Environments?
#133Earlier quoted context omitted.
I'm not sure how they've kept up, as I haven't used Qt in some time, but back in the 4.x days the documentation was absolutely stellar. Extremely thorough and almost every non-trivial feature came with code samples. I couldn't for the life of me understand why anyone was using GTK at the time.
My point is not about lack of usability or documentation. Rather that the nature of HTML+CSS+JS lets you do things you can't do as easily in either GTK or QT. In the latter, yes you can easily achieve a certain kind of UI, but not deviate from it, and even formatting/displaying a significant amount of information that doesn't fit into one of the classic widgets can be a bit of a pain.
Have you tried creating a custom date picker in those? I am fairly sure web tech would come out last with the infinite amount of divs here and there.
Re: Is there any future for the GTK-based Desktop Environments?
#134Earlier quoted context omitted.
No, and how is that even relevant?
>So why should I trust them less than my distribution? Just use google -> npm malware
I said I'm not using npm.
With my calculator flatpak I only have to trust one person and to a much lesser degree, because they declared that the calculator can't access my personal files to begin with. The same app in my distribution repository has full read-write access to all my users files, network access and much more. So yeah, I trust it more.
Distribution maintainers are nothing but a middle man, which don't even audit the code they package, so there's nothing I gain from them.
Re: Is there any future for the GTK-based Desktop Environments?
#135I think there's a future for STLWRT. All was right with the world when Linux looked like this: https://www.linglom.com/images/Linux/ChangeIPAddress/1.png I still run RHEL5 and use it everyday. I don't even consider it that old.
Hot take: Only having menus are bad UX because they force the human to search for things instead of making the computer search. I have zero fond memories of trying to find options in the giant menu structures of larger applications. I especially don't understand the reverence of the old-style start menus without a search field many seem to have.
The way I use XFCE is to mark all the applications I use as favorites so they appear on the top level menu, then it’s just two clicks to launch anything, way quicker than click-then-type-to-search.
Re: Is there any future for the GTK-based Desktop Environments?
#136Earlier quoted context omitted.
Modern versions of GTK+ support Rust, Python and Javascript. I love GNOME, but I think there's a decent group of people that would like a Rust-based GTK+ desktop environment. https://github.com/gtk-rs/gtk3-rs
This isn't some C problem, this is a GTK+ problem. There's no need to be throwing all this up-front known crap into a runtime constructed dictionary. If the widget has a "clicked" signal, there should be a typedef of the callback function appropriate for that signal and the widget struct should have a clicked_cb member for a list of callbacks of that type. Then there should simply be a unique function for installing…
The C++, Go, Rust and D bindings already do that, as does Vala, the information is all there to generate the necessary code in a statically typed language. It still wouldn't do anything for you if you want to use a dynamic language or use the xml builder functionality.
Re: Is there any future for the GTK-based Desktop Environments?
#137Earlier quoted context omitted.
Thanks for responding. I can see your angle but I don't think I agree. I'll try to respond in good faith but let me know if I've made a misapprehension. In regards to the topic of user base alienation: I do think it is an important metric to keep track of, but whether it should be prioritised is contextual. In the case of GNOME, they have frequently made a point that accessibility is a large focus for them. Accessibi…
> Or, in a sentence: you can improve these projects in the way you see fit if you take the steps required. Well yes, but actually, no. If upstream denies or ignores your pull requests, you're dead in the water. Just try and make a pull request to bring back a feature that Gnome or GTK dumped a few years prior.
> If upstream denies or ignores your pull requests, you're dead in the water
No, this is very wrong. You can maintain a fork. You can do that while maintaining positive relations with them to see if eventually they do decide to take the PR.
Of course nobody wants to do that because it's a lot of work. So what's really happening here is you're trying to play hot potato with a feature that nobody wants to maintain, not even you. I sympathize, I also have patches sitting around in various projects that went nowhere. There just isn't enough time in the day for unpaid volunteers to look at every patch.
Re: Is there any future for the GTK-based Desktop Environments?
#138Earlier quoted context omitted.
I don't think the security goals are that different, but you've asked why would I want to sandbox a calculator. Well - why would I not want that?
Look, you gave the openbsd example, and that's the right way to do it. Flatpack's are for packaged software-deployment, those are two different things. Why the need for a sandbox if you could do it much cleaner with things like pledge? But in typical linux fashion, just put another layer on top the pile of garbage so it stop's to stink for a while. >Well - why would I not want that? Then please start with the most ob…
Pledge is a bad example, it isn't applied to a lot of packages in the ports tree and it's infeasible to do it for every program. In the end you'll find you end up with the same situation as Linux: another layer on top with daemons implementing blanket security policies using pledge on behalf of the programs. Kind of like... a sandbox.
SELinux is also a bad example, even if you decide you're using that as the underlying technology you still need to implement a sandbox with various on top of it. SELinux does nothing without those rules.
Re: Is there any future for the GTK-based Desktop Environments?
#139I was an Xfce core maintainer from around 2004 to 2009. In addition to my work on Xfce, I also built a media player, and played around with some other projects that never really went anywhere. GTK2 had its warts, but it was generally fairly easy to build things, and it was fairly easy to work around things when something didn't work the way I wanted. GTK3 changed a lot of this. Many things that were previously public…
This really echoes with me too, I have a semi-big (but not so popular, at least not any more) application [1] that has gone through GTK+ 1.x, ported to 2.x, ported to GTK3, that I feel I "should" port to GTK4 since it's out. But I just can't be bothered to even try to prioritize that since all I read about v4 is anger, weird new libraries with strange names ("libadwaita" sounds like a Disney character library) and st…
You can just ignore all the lame social media drama. The main reasons to use GTK4 is probably for the performance fixes and hardware acceleration. If you don't care about that and the idea of porting seems unfun then yeah, don't bother.
But you're right there was a lot more developers and funding involved in GTK2 days.
Re: Is there any future for the GTK-based Desktop Environments?
#140Earlier quoted context omitted.
Look, you gave the openbsd example, and that's the right way to do it. Flatpack's are for packaged software-deployment, those are two different things. Why the need for a sandbox if you could do it much cleaner with things like pledge? But in typical linux fashion, just put another layer on top the pile of garbage so it stop's to stink for a while. >Well - why would I not want that? Then please start with the most ob…
Pledge is a bad example, it isn't applied to a lot of packages in the ports tree and it's infeasible to do it for every program. In the end you'll find you end up with the same situation as Linux: another layer on top with daemons implementing blanket security policies using pledge on behalf of the programs. Kind of like... a sandbox. SELinux is also a bad example, even if you decide you're using that as the underlyi…
>SELinux is also a bad example
No why? If you have the right (and correct) rules, SELinux absolutely act's as a "sandbox", that's exactly what i meant, a sandbox don't need's to be another layer of software. Run in your "namespace", can just create/access/execute/read your port, files, memory..that's it, that's a sandboxed application.
For example that "namespace-sandbox" is standard in Plan9/9front...without any additional software, just the filesystem and 9p.
https://dwalsh.fedorapeople.org/SELinux/Presentations/sandbo...