Hi lists

Followup on my previous post, this is my submission for a spec that stores
default and fallback Icon, Cursor and Sound theme with the possibility of
adding more themes or metadata to it.

https://docs.google.com/document/d/1Slqk1yTFsiTBS0P8EnDcqp5G[..]

I'm looking for more comments and would like to eventually get the process
started on submitting it.

xdg / portland / razor lists CC'd.

J. Leclanche

Fixed those, thanks.

J. Leclanche

It's unclear to me what's the exact goal of this spec: is it intended to
be used by theme authors as a hint for desktop environments? Or is it
intended to be used by desktop environments to store the theme
preferences of the user?

Thanks,

Vincent

--
Les gens heureux ne sont pas pressés.

The latter. It's currently impossible to get/set default themes (unless you
do it on an environment-per-environment basis), the spec solves that.

The following bug is linked at the bottom, the spec closes it: https://bugs.freedesktop.org/show_bug.cgi?id=43943

I would think that the right way to get the themes would be through
xsettings:

  http://specifications.freedesktop.org/xsettings-spec/xsettin[..]
  http://www.freedesktop.org/wiki/Specifications/XSettingsRegi[..]

(more settings could be added to the registry, if needed)

As for setting the theme, don't all environments provide a tool to
change the theme? Is your proposed spec intented to allow creating
third-party tools, or to script changing the theme?

Thanks,

Vincent

--
Les gens heureux ne sont pas pressés.

The issue is not just changing the theme, it's also getting it. This is an
issue for libraries that provide tools to get file paths for a theme action
(in this case, Qt's QIcon.fromTheme: http://qt-project.org/doc/qt-4.8/qicon.html#fromTheme ). And while it's true
DEs provide custom ways to change the local theme, someone may wish to
create a cross-platform cross-desktop one.

J. Leclanche

See my quote above about xsettings :-)

I don't think "may wish" is something that we'll want to cover with a
spec, to be honest. Unless there's a need acknowledged by people from
various desktops, of course.

Cheers,

Vincent

--
Les gens heureux ne sont pas pressés.

I don't believe xsettings fits the needs brought forward by this spec:
- Human readable/editable
- Ease of use and implementation
- Usable by all DEs with simple fallbacks
- Multiple-level configuration (with XDG_DATA_DIRS)

Additionally, please correct me if I'm mistaken, xsettings is barely in use
by all DEs. It would be hard to convince DEs to use it for this, I think.
Am I incorrect?

J. Leclanche

implementation for KDE (not merged) years ago.
--
Frederic Crozat

Forgive me, I've never worked with xsettings before. Is it feasible to
store theme settings in xsettings (I see it already stores cursor theme)
all the while enabling fallbacks and theme-specific settings?

J. Leclanche

1. Xsettings is a way to expose the settings to applications. It does not
define how you store the settings.

2. Xsettings, is actually used by gtk+ only. Though there is a KDE port,
it's not part of KDE. In LXDE we support Xsettings simply because we're
using gtk+. If we don't support it, our applications will clashes with
gnome ones. Gnome programs load gnome-settings-daemon, which in turns
expose gnome settings in its xsettings daemon and affect all gtk+ programs.
So, I'm forced to use xsettings. Otherwise loading gnome programs will
break my desktop settings. We don't like it at all.

3. Every desktop of course has its own way to handle settings, but it's
nice to have a common way to specify icon themes and cursors. There are
many small programs which are not bound to a specific DE. They absolutely
need this. Please, not everyone is using gnome.

The purpose of freedesktop.org is to provide cross-desktop solutions rather
than asking everyone to follow the design of the largest and most famous DE.
For someone who only use a WM like openbox or fluxbox, this spec is very
useful. Desktop independent applications can use simple ways to determine
current icon theme and sound theme without relying on DE-specific ways.
This saves all simple applications developed with pure Qt4 only. Qt4
provides no DE integration and you have to specify icon theme name yourself
in the program.

I'm with the proposed spec.

Hrm, but xsettings is already a xdg spec. That was my point. We can have
a competing spec, but unless there's a real investigation as to why
xsettings is not used everywhere, I don't see why the competing spec
would be more successful.

Vincent

--
Les gens heureux ne sont pas pressés.

I think the point he raised was that there is no xsettings backend for Qt,
which is (afaik) true.
I've read the xsettings spec now but I don't fully understand it. If
someone wishes to propose a modified version of the spec to support
xsettings, by all means. However, I see one main issue for this:

"Xsettings is not intended ... to store complex data types (other than as
strings)"

I take it a list is a complex data type -- one we need in the spec. The
spec follows the common .ini/.desktop format, which supports lists.
I see what it tries to do, but I remain unconvinced it's the best course of
action. Ini files can be read by pretty much every framework -- both python
and qt have their own builtin parsers for it, I'm sure gtk does too
(gkeyfile?), etc.

FWIS, ini files are pretty much de-facto for configuration. Easy to read,
easy to manually edit, easy to parse, many parser implementations, and most
of all reusable code throughout XDG. XSettings is a foreign format to most
devs and not human readable (I can't even find an example file anywhere...).

But I'm not sure how relevant all this is to this spec. I can see why you'd
want to use Xsettings, but from what I understand it's unable to store the
data we need in the way we need it. Ini files are used all over the place
in almost all xdg specs, hence why it was my first option. Is there any
concern against it?

J. Leclanche

nice to have a common way to specify icon themes and cursors. There are
many small programs which are not bound to a specific DE. They absolutely
need this.

To be honest, this sounds a lot like  http://xkcd.com/927/  to me. Or in
other words: hosting a spec on fdo does not guarantee adoption across
desktops - just look where the XSettings spec is hosted :-)

Regards,
Florian

I can make sure it gets into Qt at least, and I'm sure we can coordinate to
get it into GTK with backwards compatibility. I understand where you're
coming from, but this proposed standard does not compete with any other,
and it certainly does not compete with xsettings. FWIU, xsettings is a way
of storing the data -- this standard defines the data to be stored.

J. Leclanche

No, xsettings is a way of accessing the data at runtime. The "storage"
in xsettings is transient (X window properties),  so it's more like "use
xsettings instead of D-Bus" than "use xsettings instead of
~/.config/whatever".

The actual persistent configuration is an implementation detail of the
settings manager; in GNOME 3, gnome-settings-daemon is the settings
maanger, and it appears to read them from org.gnome.desktop.interface in
DConf. In GNOME 2 they were probably in GConf instead.

The point of using xsettings is that the settings are per X session
(even in the presence of remote apps, or changes being made during an
app's lifetime), as opposed to, say, being per home directory. If I run
an application via remote X, it uses the same theme, double-click
timeout, (etc.) as the local applications it shares an X session with,
rather than reading these settings from the remote home directory and
potentially getting different values.

The initial use cases for xsettings given in the spec are "double click
timeout, drag-and-drop threshold, and default foreground and background
colors" - Gtk themes presumably came later.

(I'm not saying that having settings managers get their settings for
theme or double-click time or whatever from the same place wouldn't be a
good thing, or expressing any opinion about where the Gtk theme should
be stored; just pointing out that the use of xsettings has semantics
that would not be provided by each app reading from its home directory.)

    S

Ah, I see. This is out of my league though; if someone wants to propose an
addendum I'm not against it, but I still don't see it being too relevant to
this spec, more of an implementation detail.

J. Leclanche

I guess my main point is:
Getting your spec adopted by QT and/or GTK+  makes a strong argument for
moving it to freedesktop.org. Trying to host it on fd.o in order to make an
argument for QT and GTK+ to adopt it does not.

Regards,
Florian

It tends to be a bit of a chicken and egg issue. If the spec is not
"blessed" by fdo, Qt/Gtk tend to refuse it (I would think).

I understand what you mean though. If I understand correctly, all we would
then need to do is get approval of Gtk/Qt guys. I'll ask the Qt guys but I
don't keep in touch with Gtk devs; I see there are a lot of gnome devs on
this list so if we could discuss this here, it would be great.

J. Leclanche