6 ms·

I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. Like if you want to select a

I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features. There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown. It's definitely great to see the groups working together on these projects that benefit everybody.

jacooper 4y ago
I think that's what Freedesktop does, and why Flatpak heavily relies on XDG variables.
- themodelplumber 4y ago
  Where is this chart for levels in Freedesktop? I'm only vaguely familiar with the project.
  - deleted 4y ago
    [deleted]
  - jacooper 4y ago
    I think its some kind of standards body for the Linux desktop.
derefr 4y ago
> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
- themodelplumber 4y ago
  This depends: Do you care about details, or not? If not, a hand wave in the direction of "everything's the same" will suffice and the discussion's over. OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
- traverseda 4y ago
  Because I might want to developer a new DE/toolkit/whatever and having one checklist I can refer to would really help.
- jimbo9991 4y ago
  The difference is that one of those sets of standards is actually more of a file system hierarchy and API standardization thing, whereas the uni-desktop would presumably force a particular set of gui widgets along with the filesystem hierarchy and APIs that those widgets are built on. We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility. What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
  - derefr 4y ago
    In my imagined hyper-standardized Linux landscape, there'd be a standard for e.g. the semantics of interpreting metrics in themes, and a shared superset of required icons for a theme to have; such that you could create one theme once, and have it "just work", resulting in pixel-identical widgets, under GTK, QT, Wx, etc. There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.) There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps. There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent. And so forth. The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under. There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.
reilly3000 4y ago
I really think you are into something here. Some simple rating and standard icon would help users differentiate quickly. I know and love distrowatch and the rest, but it’s definitely inaccessible for most beginners and hard to discover what the best fit is for me.
worksonmine 4y ago
The FHS[1] and XDG[2] sets the standards for the file system, and EWMH[3] communication between windows and window managers. They are all simple enough that implementing a subset doesn't make much sense. Many desktop environments tend to only list support for stuff that usually are a common problem like screen-sharing or driver support. I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy. [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... [3] https://specifications.freedesktop.org/wm-spec/latest/ https://specifications.freedesktop.org/wm-spec/latest/
- themodelplumber 4y ago
  I see what you mean. I suppose these particular existing standards come from inner-views on technicals. As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
  - worksonmine 4y ago
    Yeah, but the problem and beauty of unix is the modularity and much of those features are out of the desktop environments hands. Control panel for what printer? Which settings? What version of the drivers? At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add. Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland. Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package. KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line. Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.
calvinmorrison 4y ago
This has existed for a long time from freedesktop.org, XDG specs, window manager extended hints, and so on. And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this. More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
- vasvir 4y ago
  and now pipewire...
  - majewsky 4y ago
    Which is completely backwards-compatible with PulseAudio. Even in a Pipewire-only world, applications will for the most part be linked against libpulse like they used to, but the PulseAudio server socket is provided by Pipewire.
    - calvinmorrison 4y ago
      I mean, that's what they always say right? OSS replaced Alsa replaced arts replaced pulseaudio replaced pipewire or did I get that backwards?
yathaid 4y ago
> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.

jacooper 4y ago

I think that's what Freedesktop does, and why Flatpak heavily relies on XDG variables.

themodelplumber 4y ago
Where is this chart for levels in Freedesktop? I'm only vaguely familiar with the project.
- deleted 4y ago
  [deleted]
- jacooper 4y ago
  I think its some kind of standards body for the Linux desktop.

derefr 4y ago

> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?

themodelplumber 4y ago
This depends: Do you care about details, or not? If not, a hand wave in the direction of "everything's the same" will suffice and the discussion's over. OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
traverseda 4y ago
Because I might want to developer a new DE/toolkit/whatever and having one checklist I can refer to would really help.
jimbo9991 4y ago
The difference is that one of those sets of standards is actually more of a file system hierarchy and API standardization thing, whereas the uni-desktop would presumably force a particular set of gui widgets along with the filesystem hierarchy and APIs that those widgets are built on. We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility. What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
- derefr 4y ago
  In my imagined hyper-standardized Linux landscape, there'd be a standard for e.g. the semantics of interpreting metrics in themes, and a shared superset of required icons for a theme to have; such that you could create one theme once, and have it "just work", resulting in pixel-identical widgets, under GTK, QT, Wx, etc. There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.) There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps. There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent. And so forth. The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under. There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.

reilly3000 4y ago

I really think you are into something here. Some simple rating and standard icon would help users differentiate quickly. I know and love distrowatch and the rest, but it’s definitely inaccessible for most beginners and hard to discover what the best fit is for me.

worksonmine 4y ago

The FHS[1] and XDG[2] sets the standards for the file system, and EWMH[3] communication between windows and window managers. They are all simple enough that implementing a subset doesn't make much sense. Many desktop environments tend to only list support for stuff that usually are a common problem like screen-sharing or driver support. I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy. [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html [2] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... [3] https://specifications.freedesktop.org/wm-spec/latest/ https://specifications.freedesktop.org/wm-spec/latest/

themodelplumber 4y ago
I see what you mean. I suppose these particular existing standards come from inner-views on technicals. As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
- worksonmine 4y ago
  Yeah, but the problem and beauty of unix is the modularity and much of those features are out of the desktop environments hands. Control panel for what printer? Which settings? What version of the drivers? At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add. Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland. Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package. KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line. Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.

calvinmorrison 4y ago

This has existed for a long time from freedesktop.org, XDG specs, window manager extended hints, and so on. And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this. More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.

vasvir 4y ago
and now pipewire...
- majewsky 4y ago
  Which is completely backwards-compatible with PulseAudio. Even in a Pipewire-only world, applications will for the most part be linked against libpulse like they used to, but the PulseAudio server socket is provided by Pipewire.
  - calvinmorrison 4y ago
    I mean, that's what they always say right? OSS replaced Alsa replaced arts replaced pulseaudio replaced pipewire or did I get that backwards?

yathaid 4y ago

> I'd prefer to see more easily-communicated DE standards and published levels of adherence, rather than moving to the uni-desktop. I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.