Icons missing on ssh -X, or: no real system default for icon theme

Thu Dec 10 18:09:57 UTC 2015

On 10 December 2015 at 16:38, Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Am Sonntag, 6. Dezember 2015, 23:39:13 schrieb Albert Astals Cid:
> > El Sunday 06 December 2015, a les 13:56:19, Thorsten Zachmann va
> escriure:
> > > Hello all,
> > >
> > > I use a separate user for running calligra. I use ssh -X to login from
> my
> > > normal desktop user to my kde running user. However when I start any
> > > kde application  I have no icons.
> >
> > You are not using any desktop environment thus the Qt defaults to the
> > generic Unix icon theme, i.e. hicolor.
> >
> > Blame Linux for not having a cross desktop environment way to define
> what is
> > the icon theme to use.
>
> Question is who should set what here?
>

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.

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 (!).

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.

Someone would ask: why to expect people doing more than the companies do,
in their free time...

Browser and mobile apps do not care about this and I see no complaints that
really count.

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.

> I think there are two issues:
>
> a) with ssh -X the workspace where the GUI is shown is the origin of the
> ssh
> connection, so its settings ideally are picked up to integrate there, not
> the
> one of the system where the app is executed
>

> b) workspace icon theme might be one whose (inherited) catalog does not
> contain everything needed by the app
>
>
> NO SYSTEM SETTING FOR REAL DEFAULT ICON THEME
>
> For a) I have no clue how the needed info could be passed to the app, so it
> (or the QPA plugin) knows what to try to use in terms of
> theme/language/etc.
> Anyone with an idea here?
> Though X itself does not know about icon themes, so doing ssh -X with just
> a
> plain X server behind should also be supported, when just DISPLAY and some
> XAUTHORITY (& else?) would be set by ssh -X.
>
> Then, IIRC "hicolor" is only an imaginary fallback theme, never to be set
> used
> itself (there also is no hicolor default theme for the min. recommended
> icon
> names from fdo). So ending up with "hicolor" as theme set is an error in
> any
> case, right?
> As Albert said, seems there currently is no option to set a system-wide
> real
> default icon theme (which then would be used or overruled by whatever
> workspace in which apps run locally).
> So time to add one, via XDG. Any takers to push that? And until that has
> been
> established, any ideas how to support that by some non-standard namespaced
> KF5
> temporary solution? It would need patching of the non-KF5/Plasma Qt QPA
> plugin, to read some env var or some file, I assume?
> How would that best be implemented?
>
>
>
> HARDCODING THEMES, PLEASE ONLY AS ULTIMA RATIO
>
> For b) IMHO hardcoding apps to one certain theme should not be the only
> answer
> we can come up with. I would see that as a step back rather:
> * there would be duplicated efforts in icon creation with everyone doing
> there
> own special themed icon (copies)
>

Yes if development is split into separate efforts and results are not
merged.

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.

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.

> * at runtime even different versions of the same icon type might be used,
> as
> each app has its own copy (& not updated in-sync from normal breeze
> iconset)
> * preventing new icon themes to be created, as every app would need to be
> hacked to enable the new theme during development
>

If we use qrc, qrc can be replaced. LO and Firefox have own systems for
that.
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?)

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.

> * one currently does not know what icons the KF5/Qt5/* libs & plugins used
> by
> the app need and if they exist (imagine you hardcoded to "oxygen", and now
> the
> libs use icons only in breeze. e.g. what if "breeze" is soon dropped for
> some
> "storm"?)
>
> Instead I would like to see us rather come up with proper documentation of
> icon ids used by the apps (& libs & plugins) and provided by the different
> icon themes.
> So it is possible to check to what degree which icon themes match the set
> of
> apps/plugins/libs one uses. To decide if picking some other fancy icon
> theme
> will work for the personal needs. Or to see which icons are missings, or
> which
> are not used at all.
>

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.
It isn't up to the "promise" while themeing knobs have prominent place in
the system settings.

> In Calligra we have some initial support for overseeing icon ids used, due
> to
> some "koIcon" tagging (reusing mechanisms of "i18n"). I hope to brush that
> up
> and turn that into something for ECM, so everyone can use it. If someone is
> interested to help there, please contact me.
>

That's useful and should be promoted.

 Also when someone who uses qrc. For now Qt developers put the icons to
the qrc by hand I guess, without scripts.

> (When creating app bundles for those alien systems like Android, Windows,
> OSX,
> where each bundle rather needs their own copies of all used libs&resources,
> knowing what subset of icons are used by the own stack allows to avoid to
> include the complete big Breeze icontheme).
>

Aren't icons compiled into mobile apps by the SDKs usually?
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.
Sometimes this is like using a custom script to sort a 3-element list. 2
hours of extra work.

Thanks for the reply, Friedrich.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151210/62f65f8a/attachment.html>