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
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
