<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 December 2015 at 16:38, Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Sonntag, 6. Dezember 2015, 23:39:13 schrieb Albert Astals Cid:<br>
> El Sunday 06 December 2015, a les 13:56:19, Thorsten Zachmann va escriure:<br>
> > Hello all,<br>
> ><br>
> > I use a separate user for running calligra. I use ssh -X to login from my<br>
> > normal desktop user to my kde running user. However when I start any<br>
> > kde application I have no icons.<br>
><br>
> You are not using any desktop environment thus the Qt defaults to the<br>
> generic Unix icon theme, i.e. hicolor.<br>
><br>
> Blame Linux for not having a cross desktop environment way to define what is<br>
> the icon theme to use.<br>
<br>
Question is who should set what here?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I think almost nobody cares. Worse, there are many directions and this is natural as a source of differentiation. We can't teach GTK+, where G is now GNOME) team how/what to do. And we can't ask to kill differentiation efforts.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">For me it all starts from the simple fact that Breeze developers had to invest time into maintaining 24px icons -- even this basic parameter 24 vs 22 isn't harmonized (!).<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">So for me this themeing is increasingly becoming utopia and distraction. Like tuning your new Hummer to look like a family van. Nobody sues you for doing that privately but don't expect the factory to ship tunning facilities and knobs of all sorts. Somebody else who charges extra can tune that for you and maybe give you some warranty, but not the factory. Nobody blames factory for having finite set of variants.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Someone would ask: why to expect people doing more than the companies do, in their free time...<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>Browser and mobile apps do not care about this and I see no complaints that really count.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">And last, there are areas that are really worth discussion. We lack APIs and maybe tooling to support dark/light themes for icons. Because of that we already have redundancy here and icon maintainers have to overcome the issues but they can't fully do that at this level. QStyle does not support different selected/unselected icons or icons that should be filled with color before actual rendering. I don't even mention semantic coloring as named shapes in SVG. This all was not needed in times when we had clear black borders or shadow around icon's shape (themes such as crystal or oxygen). Now if user picks a blue colour for a mono icon set, they look interesting on a blue 'selected' button.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think there are two issues:<br>
<br>
a) with ssh -X the workspace where the GUI is shown is the origin of the ssh<br>
connection, so its settings ideally are picked up to integrate there, not the<br>
one of the system where the app is executed<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
b) workspace icon theme might be one whose (inherited) catalog does not<br>
contain everything needed by the app<br>
<br>
<br>
NO SYSTEM SETTING FOR REAL DEFAULT ICON THEME<br>
<br>
For a) I have no clue how the needed info could be passed to the app, so it<br>
(or the QPA plugin) knows what to try to use in terms of theme/language/etc.<br>
Anyone with an idea here?<br>
Though X itself does not know about icon themes, so doing ssh -X with just a<br>
plain X server behind should also be supported, when just DISPLAY and some<br>
XAUTHORITY (& else?) would be set by ssh -X.<br>
<br>
Then, IIRC "hicolor" is only an imaginary fallback theme, never to be set used<br>
itself (there also is no hicolor default theme for the min. recommended icon<br>
names from fdo). So ending up with "hicolor" as theme set is an error in any<br>
case, right?<br>
As Albert said, seems there currently is no option to set a system-wide real<br>
default icon theme (which then would be used or overruled by whatever<br>
workspace in which apps run locally).<br>
So time to add one, via XDG. Any takers to push that? And until that has been<br>
established, any ideas how to support that by some non-standard namespaced KF5<br>
temporary solution? It would need patching of the non-KF5/Plasma Qt QPA<br>
plugin, to read some env var or some file, I assume?<br>
How would that best be implemented?<br>
<br>
<br>
<br>
HARDCODING THEMES, PLEASE ONLY AS ULTIMA RATIO<br>
<br>
For b) IMHO hardcoding apps to one certain theme should not be the only answer<br>
we can come up with. I would see that as a step back rather:<br>
* there would be duplicated efforts in icon creation with everyone doing there<br>
own special themed icon (copies)<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Yes if development is split into separate efforts and results are not merged. <br><br>Not if hardcoding happens on build time to reduce dependencies on constantly moving base icon set. I imagine the breeze-icons repo would include more and more icons originating from apps as a central place. The same time, renames and replacements won't affect already deployed apps if apps will maintain own snapshots of icons they use. After all apps' release is a snapshot of its source code too, and releases are not in sync.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">No app uses all the icons, and all Breeze icons take like 6M compressed. In a world where apps start to be deployed using VMs.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* at runtime even different versions of the same icon type might be used, as<br>
each app has its own copy (& not updated in-sync from normal breeze iconset)<br>
* preventing new icon themes to be created, as every app would need to be<br>
hacked to enable the new theme during development<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">If we use qrc, qrc can be replaced. LO and Firefox have own systems for that.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">If someone really wants to theme an app, he/she will do that. Example: The breeze team greatly themed LO despite it using completely separate system. LO is Breeze-themed before we, in Calligra, even collected a list of TODOs (!). And I have found official version for Windows with this theme and use. (still no opensuse 13.2 version, that's an irony -- where's the benefit of modularization?)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Plasma 4 was themeable but most themes were like variants of the same original theme. It was easy to have icons out-of-place or non-contrasting. Icon theme and widget theme was so often not independent, this should be known as important fact: workspace's and application's look is a sum of icons+style+layouts. Just like I can't use any kind of wheels for a given car, I need to know the rules to be safe.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* one currently does not know what icons the KF5/Qt5/* libs & plugins used by<br>
the app need and if they exist (imagine you hardcoded to "oxygen", and now the<br>
libs use icons only in breeze. e.g. what if "breeze" is soon dropped for some<br>
"storm"?)<br>
<br>
Instead I would like to see us rather come up with proper documentation of<br>
icon ids used by the apps (& libs & plugins) and provided by the different<br>
icon themes.<br>
So it is possible to check to what degree which icon themes match the set of<br>
apps/plugins/libs one uses. To decide if picking some other fancy icon theme<br>
will work for the personal needs. Or to see which icons are missings, or which<br>
are not used at all.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Yes, sad aspect of themeing is that styles do not fit to themes sometimes, is that themes break silently and not in the app, what can be surprising for average user. Maybe that's an issue with a shared infra. <br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">It isn't up to the "promise" while themeing knobs have prominent place in the system settings.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In Calligra we have some initial support for overseeing icon ids used, due to<br>
some "koIcon" tagging (reusing mechanisms of "i18n"). I hope to brush that up<br>
and turn that into something for ECM, so everyone can use it. If someone is<br>
interested to help there, please contact me.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">That's useful and should be promoted.</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"> Also when someone who uses qrc. For now Qt developers put the icons to the qrc by hand I guess, without scripts.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
(When creating app bundles for those alien systems like Android, Windows, OSX,<br>
where each bundle rather needs their own copies of all used libs&resources,<br>
knowing what subset of icons are used by the own stack allows to avoid to<br>
include the complete big Breeze icontheme).<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Aren't icons compiled into mobile apps by the SDKs usually?<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">And if someone ports the app, sometimes with completely custom/separate UI and the same internals, even mapping icon names to the target system names isn't too useful.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Sometimes this is like using a custom script to sort a 3-element list. 2 hours of extra work.<br></div></div></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Thanks for the reply, Friedrich.<br></div><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>