KColorScheme

[Matthew Woehlke]

On 2012-07-20 12:09, David Faure wrote:
> On Thursday 19 July 2012 22:18:36 Matthew Woehlke wrote:
>> because I don't have a KDE build at the moment :-(
>
> Too bad, I wanted to ask for your help on something related...

I'm hoping https://bugs.kde.org/show_bug.cgi?id=303825 may finally be 
enough motivation to fix that :-).

> I don't know if you followed the "KDE Frameworks" effort, but we're basically
> trying to upstream as much of the kdelibs functionality as possible, into Qt.
> Anything that makes sense for all Qt applications (i.e. which isn't tied to
> the KDE workspace or community), should go into Qt.

Not really, though I've heard of it.

Actually, on a related note, I did hear about KDebug being a candidate 
for the effort. Two things I don't like about KDebug, however, are a: 
the area ID's are not developer-mnemonic (although that seems to have 
changed since what I remember), and b: executing kDebug() requires 
locking a mutex.

I wanted similar functionality for a project I work on, that couldn't 
use kdelibs (too big a dependency) and ended up implementing something 
similar, except it looks like:

   qteDebug(xMyArea) << {...};

...where xMyArea is a pointer to a function returning a pointer to a 
(singleton) opaque object representing the debug area. Since (AFAICT?) 
the 'active' state of a debug area cannot be changed at run-time, it 
seems like KDebug could do the same by using an opaque pointer instead 
of an int. Locking would only be needed when the static object is 
created, i.e. on first use of the area.

Let me know if that sounds interesting. We're trying to get permission 
to release the source code for our project, though it might be another 
few months before we can get approval for that particular piece. However 
I can describe the general idea in more detail if you like.

> Do you think KColorScheme could be replaced with a Qt feature?
> What would that be? Would more enums in QPalette (turning them into flags,
> actually, to combine several of the different enums from KCS) be enough?

What I would REALLY like to see in Qt is KColorUtils. IMHO it's silly 
that the features KCU provide were not in Qt4.

My ideal would be to see the full "suite" of KColorScheme colors 
available in Qt. While they're not needed 90% of the time, they're 
amazingly useful that other 10%, and there have been a number of times 
I've either wished to have them in a Qt-only appliction, or used kdelibs 
for an application that otherwise could be Qt-only specifically for 
KColorScheme (qgit comes strongly to mind).

I think going with flags is probably a good idea; I would probably do 
that by keeping the existing sets, roles and shades as distinct, but 
allow combining them into one variable, e.g.:

QPalette::ViewSet | QPalette::Background | QPalette::LinkRole | 
QPalette::DarkShade | QPalette::Disabled

...and it should go without saying that (as now) the user defines a much 
smaller subset of the colors possible from this, and that the rest are 
derived computationally (shades in particular).

The defaults (0-values) probably should be Background, NormalRole, and 
NormalShade (picking Background as you'll most often want shades of the 
Background | NormalRole). The default set is probably less important, 
but probably would be ViewSet or WindowSet; probably ViewSet since 
that's what e.g. QPalette::text() returns. State shouldn't be 0-valued 
ever, since at least state should have a 'current default' that can be 
set on the palette. I can make a good argument that set should be 
likewise (which, unlike state having four possible values, has five 
possible values, so could just reserve a zero-value one for 'current').

The only catch I see there is that some combinations don't make sense. 
Certainly we can devote a few bits to state, set and shade. However, for 
the rest, I think that another few bits would specify one of foreground, 
background or decoration, and the remaining role bits would be 
interpreted differently for fg/bg versus decoration. Obviously, this 
implies that some combinations (e.g. Decoration | Neutral) are not valid.

(I'll take the opportunity to point out that I still consider it a bug 
that inactive and disabled states are mutually exclusive.)

> Well, even if you can't work on this at the moment, your input by email would
> still be very welcome, so that we have an idea of what would be the ideal
> solution about this.

Sure; happy to help. (Finding time for talking tends to be easier than 
finding time for build cycles.)

-- 
Matthew