|
|
Screenshot_20191128_134814.png (58,556 bytes) |
|
|
Is it possible to load a different graphic, if the icon is disabled? (either use a different folder, or prepend a short "DISABLED" to the icon's filename?) |
|
|
Likely fixed, but assigning to Martin to check |
|
|
The problem is still visible in 1.6.0 with 1.5.1 Dark icons. Operating System: Manjaro Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 Kernel Version: 6.6.9-1-MANJARO (64-bit) Graphics Platform: Wayland text1-2-9.png (177,403 bytes) |
|
|
But in 1.7.0.svn image.png (25,054 bytes) |
|
|
Okay. So, after looking into things a bit I think the following is happening: Disabled Icons are rendered as greyscale, the problem is that the dark icons are already grey. I see the following solutions here: Either introduce more color to the Dark Icon theme, something I could probably work on, or change how the Icons are managed within Scribus when they're disabled; which would mean getting into the code. And then designing/editing icons and save them for the disabled state. The former would probably be quicker. Give me a few minutes to create a 1.6.1 dark theme – i have ideas that will probably not look too shabby. |
|
|
This is now probably moot, since 1.7.0.svn has a nice new icon theme, but for the old ones, see the attachment. |
|
|
I extracted and copied "1_6_0_dark" folder to "/usr/share/scribus/icons/" and added "/usr/share/scribus/icons/1_6_0_dark.xml" then "Scribus 1.6.0 Dark" entry appeared in Preferences, but even if I select it the icons are still looking the same. |
|
|
Forgot to edit the XML-file. Right. Changed it in the attachment. The old XML is still pointing to the 1_5_1_dark folder, which is probably why the icons don't change. |
|
|
By the way, there should be yellow highlights when the icons are active. When they're inactive they'll still look grey, because scribus is rendering them in software to greyscale. |
|
|
@Luna: What did you change? (I have not tested) If we brought that version in, would we also need new light icons? It would not make much sense to include 2 dark palettes of icons. (Plus, need to confirm if your changes are licence compatible with existing) |
|
|
The solution to color (a part of or all of) a limited number of icons as yellow is not working for all toolbar icons. Some enabled icons are still looking gray like disabled ones. Why not color all enabled icons by pure white and disabled ones by gray. image1-6.png (153,606 bytes) |
|
|
@cbradney Can we safely use 1.7.0 icons in Scribus 1.6.0 ? |
|
|
No, 1.7.0 icons are SVG based so not directly. If someone, maybe @nitramr or some with him, want to work on a single use export of those icons for the right sizes, plus all the renaming, we could use them, yes. |
|
|
QIcon supports different images for different icon states, i.e. "normal" and "disabled". If no image is specified for a disabled state, Qt is generating this image based on the UI theme palette colors. Perhaps the color contrast between "normal" and "disabled" is not much in Breeze theme (and in my case Adwaita dark too). I see 3 options how we can fix that. 1. Additional "disabled icon set" We can create a darker greyscale version of all existing icons and add them to the icon theme. The IconManager can be extended to add an image for "normal" and another one for "disabled" state. 2. Automatic generated disabled state similar to 1) the IconManager could render the disabled state itself, so we don't need additional images in icon set. In QIcon code I found this: QStyleOption opt(0); opt.palette = QApplication::palette(); QPixmap generated = QApplication::style()->generatedIconPixmap(mode, pm, &opt); We could define a temporary custom QPalette for the disabled state in IconManager and set the original icon pixmap for normal state and our modified pixmap for disabled state. 3. Custom Application Style As I said, Qt uses colors from the application palette. We can create a custom QStyle theme for Scribus and override the function for icon rendering. See https://doc.qt.io/qt-6/qcommonstyle.html#generatedIconPixmap Option 2 looks like less effort for now. Option 3 has much more opportunities to have the application style under more control when Scribus runs on different operating systems. The attached image shows the "normal" and "disabled" state under Adwaita dark theme. Bildschirmfoto vom 2024-01-05 19-59-00.png (7,732 bytes) |
|
|
@nitramr >Perhaps the color contrast between "normal" and "disabled" is not much in Breeze theme It's not specific to Breeze theme, because it happens with all 4 themes: Fusion, Windows, Oxygen and Breeze. I'm running KDE Plasma 5.27.10 with official Dark Breeze theme, and all other Qt apps show clear difference between enabled and disabled icons. |
|
|
@nitramr: With the proliferation of Wayland that seems to be accelerating, we may need to release a Qt6-based stable version this year, so 1.7.0 would move to stable 1.8.0. Any efforts really need to go into 1.7.0 now, and limited effort into 1.6.x that does not either stablise/fix it, or also contribute to 1.7.x. We certainly need to choose the most efficient fix for this that could be a part of 1.6.x series. |
|
|
@cbradney I only changed the icons that could be disabled to have some yellow in it. It's possible to make them almost completely white to have even more contrast, though I also wouldn't make them completely yellow, as I don't think it would look any good. If the solution with yellow highlights and a whiter tone of the icons work, I can easily change those – since they are all based on the 1_5_1 icon theme, there shouldn't be any license problems. It would also make sense to change the corresponding light icon theme to match the dark one. @nitramr From a design point of view I'd like a disabled icon theme. Then it would be possible to create "broken" icons, ones that look as if they're broken by a line pattern. But since this is not happening in 1.6.1. |
|
|
Here's another version. If that's okay, I can look into making a corresponding light theme. That is editing the existing icons to have some color at the same locations as this one. |
- Anonymous
