The tendency to create and maintain distribution specific applications seems somewhat strange to me.
-
The tendency to create and maintain distribution specific applications seems somewhat strange to me. To me it makes more sense to just focus on a set of standard applications and not insist on them being developed specifically for that distro or DE (NIH).
Also, as a user, I think it would be great if some of these applications were more cross platform-oriented, instead of requiring tons of e.g. GNOME/KDE/Cosmic deps.
But maybe there are great reasons behind them that I just don't know. #linux
@marcusxms I agree.
I think that is the result of a difference in the overall vision between the various projects. There's no streamlined process to unify, say, the visual styling of apps on the Linux desktop, just people in-between trying to bridge the projects with "glue code" (like Linux Mint still maintaining GTK3 to preserve a coherent look of the controls and window styling)
The lack of a streamlined UI is the backside of the medal of having complete creative freedom I guess.
-
The tendency to create and maintain distribution specific applications seems somewhat strange to me. To me it makes more sense to just focus on a set of standard applications and not insist on them being developed specifically for that distro or DE (NIH).
Also, as a user, I think it would be great if some of these applications were more cross platform-oriented, instead of requiring tons of e.g. GNOME/KDE/Cosmic deps.
But maybe there are great reasons behind them that I just don't know. #linux
@marcusxms what do you mean by for example 'KDE specific dependencies' or 'gnome specific dependencies'?
-
@marcusxms what do you mean by for example 'KDE specific dependencies' or 'gnome specific dependencies'?
@svuorela For one there are GTK and QT dependencies, but sometimes when I try to install a package it wants to pull in various GNOME or KDE programs as deps too, like gnome-desktop or knotifications.
Sometimes it's maybe 20 MB and other times it's 100s of MB's of unrelated programs, which will now also take time and resources to update during system updates.
Some issues are related to my compositor, though, not having a desktop portal, so it relies on GNOME's, which fx. pulls in nautilus.
-
@marcusxms I agree.
I think that is the result of a difference in the overall vision between the various projects. There's no streamlined process to unify, say, the visual styling of apps on the Linux desktop, just people in-between trying to bridge the projects with "glue code" (like Linux Mint still maintaining GTK3 to preserve a coherent look of the controls and window styling)
The lack of a streamlined UI is the backside of the medal of having complete creative freedom I guess.
@simonjust Good points. I've heard some talk of something like a unified theme engine in KDE (called "Union"). Maybe if theming was more standardized fx. in Wayland, applications could be more themable across different UI toolkits, so fx. nautilus might look like a QT app in KDE or vice versa.
That said I'm certainly no expert on theming (I've only made very simple things in QT and GTK),, so it's possible it's simply not a realistic or even desirable goal. There's strength in diversity, too.
-
The tendency to create and maintain distribution specific applications seems somewhat strange to me. To me it makes more sense to just focus on a set of standard applications and not insist on them being developed specifically for that distro or DE (NIH).
Also, as a user, I think it would be great if some of these applications were more cross platform-oriented, instead of requiring tons of e.g. GNOME/KDE/Cosmic deps.
But maybe there are great reasons behind them that I just don't know. #linux
Maybe if this software wasn't so much thought of as a GNOME or KDE project, but mostly a Linux project, that developers on either could contribute to.
Of course sometimes visions greatly differ as said, not just in terms of UI but functionality, and in such cases separate projects makes sense. And naturally anyone should be free to create something new, if they want, fx. to get full control over it.
But sometimes it just seems like "we need X application in our DE' and then NIH kicks in.
-
@svuorela For one there are GTK and QT dependencies, but sometimes when I try to install a package it wants to pull in various GNOME or KDE programs as deps too, like gnome-desktop or knotifications.
Sometimes it's maybe 20 MB and other times it's 100s of MB's of unrelated programs, which will now also take time and resources to update during system updates.
Some issues are related to my compositor, though, not having a desktop portal, so it relies on GNOME's, which fx. pulls in nautilus.
@marcusxms knotification is a great example of you just getting irrationally annoyed with a small library containing a K in it's name.
On Linux, what it does, is that for popup notifications, it either sends a dbus message to the standardized host if exists and else it paints it itself.
For windows, Mac and android it also forwards to native implementations. All using Qt datatypes.
Of course, every application could code it themselves, but that's silly.Most of KDE's frameworks are like this.
-
@marcusxms knotification is a great example of you just getting irrationally annoyed with a small library containing a K in it's name.
On Linux, what it does, is that for popup notifications, it either sends a dbus message to the standardized host if exists and else it paints it itself.
For windows, Mac and android it also forwards to native implementations. All using Qt datatypes.
Of course, every application could code it themselves, but that's silly.Most of KDE's frameworks are like this.
@svuorela Notifications are rarely a critical component of an application, but if they are, it could depend on there being any application which says it supports notifications (anything that implements the protocol) and not care which one it is, instead of specifically depending on one from KDE.
Implementing the daemon itself is certainly silly, yes.
-
@svuorela Notifications are rarely a critical component of an application, but if they are, it could depend on there being any application which says it supports notifications (anything that implements the protocol) and not care which one it is, instead of specifically depending on one from KDE.
Implementing the daemon itself is certainly silly, yes.
@svuorela That said, that may not work that well outside Linux, so it could also be the case that it's the protocol that's lacking here. I don't have an in-depth understanding of notifications (aside from setting up a daemon and using notify-send), but it was also just an example.
-
@svuorela Notifications are rarely a critical component of an application, but if they are, it could depend on there being any application which says it supports notifications (anything that implements the protocol) and not care which one it is, instead of specifically depending on one from KDE.
Implementing the daemon itself is certainly silly, yes.
@marcusxms for practical purposes on linux it is just a client library doing the similar thing to notify send using qt datatypes and funneling action buttons back with a qt friendly API - it is using the standardized DBUS API underneath for the common case.
But again, this is just an example of convenience and code sharing. Most other K libraries are the same. Small qt addons or qt friendly API's on top of others.
-
@marcusxms for practical purposes on linux it is just a client library doing the similar thing to notify send using qt datatypes and funneling action buttons back with a qt friendly API - it is using the standardized DBUS API underneath for the common case.
But again, this is just an example of convenience and code sharing. Most other K libraries are the same. Small qt addons or qt friendly API's on top of others.
@marcusxms I could code the simple versions of those myself, but by using a tested library I get a lot for free.
There is also not that many things in kwidgetaddons library, but it's a small library gluing existing Qt components together in nice ways. I could reinvent those wheels myself, but I don't think that's good use of time.
KDE has spent a lot of resources making many of their libraries small and easy available. And of course we hope and expect people to use them rather than replace.
-
@svuorela For one there are GTK and QT dependencies, but sometimes when I try to install a package it wants to pull in various GNOME or KDE programs as deps too, like gnome-desktop or knotifications.
Sometimes it's maybe 20 MB and other times it's 100s of MB's of unrelated programs, which will now also take time and resources to update during system updates.
Some issues are related to my compositor, though, not having a desktop portal, so it relies on GNOME's, which fx. pulls in nautilus.
@marcusxms but a lib called 'gnome-desktop' does sound like it is more 'very deep desktop integration' - KDE also have libraries for deep desktop integration, and they are in most applications build time optional (but most binary distros compiles with all features) - and even then, they're mostly thin client libraries that neuter themselves on other desktops.
A thing that carries many megabytes though is icons after gnome abandoned the shared specifications for providing icons.
-
@simonjust Good points. I've heard some talk of something like a unified theme engine in KDE (called "Union"). Maybe if theming was more standardized fx. in Wayland, applications could be more themable across different UI toolkits, so fx. nautilus might look like a QT app in KDE or vice versa.
That said I'm certainly no expert on theming (I've only made very simple things in QT and GTK),, so it's possible it's simply not a realistic or even desirable goal. There's strength in diversity, too.
@marcusxms
I certainly hope there will be some kind of standardisation some day, I get tics from seeing different UI themes on the my desktop
Btw. have you seen this:
https://wayland.app/protocols/A great way of tracking the state of various Wayland protocols.
