QIcon::Mode and QIcon::State about qtawesome HOT 10 CLOSED

I think this is a very interesting option to create.
So yes, I agree this should be implemented!

I need to find some time to 'research' and implement it.

from qtawesome.

I can help if you want. Meeting on #IRC one of those night?

from qtawesome.

Btw... I'm looking at the code right now and
you already can supply different icons for the different modes
(via text-selected, text-active, text-disabled you can supply different icons-symbols for different modes)

(fragment of painter in QtAwesome.cpp)

        if( mode == QIcon::Disabled ) {
            color = options.value("color-disabled").value<QColor>();
            QVariant alt = options.value("text-disabled");
            if( alt.isValid() ) {
                text = alt.toString();
            }

I can expand this functionality by adding an extra option for the on/off state
By adding extra options (with the -off postfix)

text-off
color-off
text-disabled-off
color-disabled-off
.. etc..

What's your idea about this?

from qtawesome.

I would suggest to keep mapping on "color" and "text" for the "normal mode" to avoid breaking compatibility with old code.

This is the mapping I suggest:
text ->(map to)-> text-normal-on
color ->(map-to)-> color-normal-on

and then, for the rest
text-normal-on
text-normal-off
text-disabled-on
text-disabled-off

I think that the API should be modified/updated so we can still use the QtAwesome::icon to generate icon quickly without providing 1 thousand parameter in a QVariantMap, what do you think?

from qtawesome.

I've also updated the sample an the README.md to explain how to use it

from qtawesome.

Hello,

This change (8c99d81) broke the library function for me. Tested with Qt5.9 on Ubuntu and Windows.

I found out, that the new function optionKeysForModeAndState() will sometimes return an empty string for the text property. (mostly with the active mode). Therefor, no icon will be painted in these cases.

While working on a fix (https://github.com/JanLochi/QtAwesome/tree/fixModeStateEnhancement), I realized that this new functionality maybe won't work as intended. At least as far as I can tell.
The new sample demonstrates the use of a checkable QPushButton with different icons for each state.
As far as I understand it, the checked property of the button will influence the choice between QIcon::On and QIcon::Off.

Now the possible issue: How to decide which state has precedence over which? In the example, the color switches to black because of the active mode, whenever I tab to the button or click it.
Maybe On/Off should be considered first, but the disabled state is even more important.

Any ideas on how to proceed, or did I mixed something up?

from qtawesome.

Hmmm this is interesting..
It should work as before when you don't supply the extra modes and states
I will try to research and fix this asap...

(note so self: https://doc.qt.io/qt-5.10/qtwidgets-widgets-icons-example.html)

from qtawesome.

@JanLochi I've merged your commit. It think this is a solution (for the time being).
I didn't have the time to figure out the precedence of all options.

from qtawesome.

Thank you for the update. Glad to contribute.

from qtawesome.

Thank you for your contribution!! 😄
(Sorry for the delay.. )

from qtawesome.