2 ms·

> 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 e

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

by derefr 4y ago

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.