Solving the colour scheme issues properly

[Fredrik Höglund]

On Tuesday 03 July 2007 21:30, Maksim Orlovich wrote:
> > Problem 1: KDE applications that are run as a different user (sudo) or
> > remotely over the network do not have access to the KDE settings of the
> > desktop they run in.
> >
> > Problem 2: KDE applications running in GNOME do not pick up the
> > user-chosen
> > colours and look out of place. Non-KDE applications running in KDE can
> > only
> > pick up the user-chosen KDE colours if they parse the configuration files.
> 
> XSettings might be a solution to these 2, but I am not sure the 'details'
> are solvable, since different toolkits use different palettes. Fredrik can
> say more than I do.

Right, the idea behind XSETTINGS is basically that each desktop provides
its own settings server that publishes settings such as double-click time,
fonts, colors, icon theme and so forth in a named X11 property.

Applications read and use the settings from this property instead of from
configuration files, when they detect that such a settings server is running.

This way all applications will (in theory) always look and behave consistently
with other applications in the environment they're running in.

You can find a list of all keys that have been standardized upon at:

http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry

I should mention though that we don't implement this in KDE currently.

There was a discussion recently on the XDG list about adding the color roles
shared by Gtk+ and QPalette, and moving them into the Net namespace.

> >
> > Problem 3: Qt applications running in KDE are usually painted with KDE
> > styles
> > but do not follow the user chosen KDE colour settings, which leads to
> > inconsistencies.
> 
> That really shouldn't happen for most apps, since we export the default
> KDE palette to qtrc (of course, that stuff might need fixing in trunk).
> I don't see what more we can do, and if the app feels like forcing a hot
> pink palette.....

I believe krdb still only exports color settings to Qt 3 apps.
 
> > Problem 4: Some HTML pages define text and background colours that do not
> > have
> > enough contrast with the user-chosen highlighting colours (selection,
> > focus,
> > hover). The same applies to text in documents, or to other places where
> > the
> > global colour scheme is (correctly or incorrectly) not used.
> 
> There is code in KHTML that tries to address that. Are there any instance
> you know of where it doesn't work? Oh... DId you mean inside widgets, not
> normal selected text?
> 
> >
> > Problem 5: KColorScheme has two sorts of colour roles:
> > a) colours that are intended for applications (ForegroundRole and
> > BackgroundRole) and will be passed on to styles by changing the QPalette
> > of
> > an item
> > b) colours that are mainly useful for styles (DecorationRole and
> > ShadeRole)
> > and which cannot be passed on to the styles via the current implementation
> > of
> > QPalette
> 
> Well, (b) is the technical problem, yes. The two sorts of roles is more of
> an API design issue. Which is a concern too, since QPalette is confusing
> enough, but KColorScheme has its own terminology. I'll skip commenting on
> this part, though, since there are people better than me when it comes to
> API design.

It has already been commented on by me in one of the numerous
threads Matthew has started on this subject.
 
> > Idea A (for problems 1-3):
> > Plasma sets an Xatom name for each colour role. All applications running
> > on
> > the same X display can access these. We should try to agree with GNOME on
> > a
> > shared naming convention to achieve a freedesktop.org standard.
> > See http://en.wikipedia.org/wiki/X_Window_core_protocol#Atoms
> > (This idea has already been discussed by some GNOME developers, but I do
> > not
> > know whether they have implemented it.)
> 
> XSettings does stuff sort of like this. However, Plasma is probably the
> wrong app to do it, kded will likely be a better fit.

This is precisely what XSETTINGS is.

I wouldn't choose Plasma either, but I'm not sure if kded itself is the best
fit. It needs to be a process that's always running when the KDE desktop
is, but never when another desktop is being used.

Regards,
Fredrik