KColorScheme

[David Faure]

On Friday 20 July 2012 14:19:47 Matthew Woehlke wrote:
> 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

Good to see we have the same idea.

(Disabled is already orthogonal, that's ColorGroup, see below)

In practice though, this means making some of the current flags orthogonal, no?
(I'm only looking at which changes are BIC, i.e. need to be done for Qt-5.0)

If I just add Q_DECLARE_FLAGS(ColorRoles, ColorRole) and switch the api to use ColorRoles instead of ColorRole everywhere, then this doesn't seem to be enough, we also need to change some of the current enum values.
E.g. Button becomes Button = Background | ButtonStuff (?) and
ButtonText becomes Foreground | ButtonStuff (?), right?

Could you make a complete proposal for how the current ColorRole enum should be changed?

The current stuff is
    enum ColorGroup { Active, Disabled, Inactive, NColorGroups, Current, All, Normal = Active };
    enum ColorRole { WindowText, Button, Light, Midlight, Dark, Mid,
                     Text, BrightText, ButtonText, Base, Window, Shadow,
                     Highlight, HighlightedText,
                     Link, LinkVisited,
                     AlternateBase,
                     NoRole,
                     ToolTipBase, ToolTipText,
                     NColorRoles = ToolTipText + 1,
                     Foreground = WindowText, Background = Window
                   };

No need to introduce unused orthogonal concepts for now (such as "ViewSet" or "DarkShade",
if I understand these correctly), but we at least need to split the background and text colors
for the same things into "one value in the main enum | background or foreground".

This only needs some work in an email, no compiler needed, can you look into it? ;)


PS: re "qteDebug(xMyArea) << {...};", there's already something for this, currently a separate addon but planned
for inclusion into Qt-5.1, see https://bugreports.qt-project.org/browse/QTBUG-19536

> Since (AFAICT?) the 'active' state of a debug area cannot be changed at run-time,

Actually in KDE4 it can, there's a dbus call to reload the kdebug settings. This probably won't be there in Qt5 though
(no QtDBus dependency in QtCore).

All in all, we're rather covered in the qDebug topic, while I really need your help on the QPalette topic :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5