Re: [kde-artists] Icon naming issue
On Friday 27 April 2007 21:58:27 Kenneth Wimer wrote: On Friday 27 April 2007 21:39:48 James Richard Tyrer wrote: Patryk Zawadzki wrote: On 4/27/07, James Richard Tyrer [EMAIL PROTECTED] wrote: As I see it, the problem is that we don't have a proper set of HiColor icons. Someone moved all the existing HiColor icons to KDEClassic and for some reason all new HiColor icons were removed. Then some HiColor icons were renamed CrystalSVG and some CrystalSVG icons were renamed HiColor. Now GNOME seems to have emulated us and removed their HiColor icons as well. To me this is a real mess. Why is this bad? Apps drop their default icons to hicolor so these are picked up regardless of the theme in use. HiColor is not default, it is fallback. Semantics Why should any theme put its icons there? If a theme is complete, no icons will ever need to be searched for in hicolor. If it is not complete, it should provide its own list of parent themes (e.g. based on CrystalSVG) and the missing icons should be picked from the parent theme, so again, no need to search hicolor. While I half agree with you, the point here is the standard: Again, semantics... http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.h tm l Sorry for saying this was a case of misunderstanding, it is not...as you mentioned in this link the spec says: ' In order to have a place for third party applications to install their icons there should always exist a theme called hicolor ' I am not sure how you interpret this to mean that hicolor should be a full icon theme on it's own. Ken ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
Matthias Clasen wrote: SNIP The spec simply states that hicolor will always be tried, and that it will be the last. Well maybe. It clearly states that, but I think that it also states additional things. That means that it is a good place to install icons to, which you need to be available regardless which theme the user selects. But, that currently doesn't work since KDE first tries Default/CrystalSVG and GTK/GNOME first tries: Gnome. So, icons installed in HiColor are not available regardless. They are only available if they don't exist in Default/CrystalSVG or Gnome (depending on which DeskTop you are running). -- JRT ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
On Tuesday 01 May 2007 03:38:27 James Richard Tyrer wrote: Yes, you are absolutely correct about that. So I made the neutral, unthemed, generic icons and installed them in HiColor. They were removed from SVN without even consulting me. I was told that I could install them in KDEClassic (which they are not) and they are not available for fall back there. If you have a problem with KDE, why don't you take it up on a KDE list? Thanks, Ken ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
Kenneth Wimer wrote: On Tuesday 01 May 2007 03:38:27 James Richard Tyrer wrote: Yes, you are absolutely correct about that. So I made the neutral, unthemed, generic icons and installed them in HiColor. They were removed from SVN without even consulting me. I was told that I could install them in KDEClassic (which they are not) and they are not available for fall back there. If you have a problem with KDE, why don't you take it up on a KDE list? My apologies. What I should have said was that these icons were removed from KDE SVG for the stated purpose of complying with the standard. My point is not about KDE but rather about the interpretation of the standard. While I believe that my interpretation of the standard is correct, I do think that the standard document could be clearer so that various developers do not argue about what it means. -- JRT ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
On Mon, 2007-04-30 at 11:57 -0700, James Richard Tyrer wrote:
It is recommended that the icons installed in the hicolor theme look
neutral, since it is a fallback theme that will be used in combination
with some very different looking themes.
My reading of this is that HiColor is a fallback theme that should
contain neutral ('unthemed', generic, or whatever) icons and that it
should be a full set of icons -- if not a full set, what will there be
to fall back to?
From my perspective, the whole full theme vs fallback is a total red
herring. A full theme is an impossibility anyway, until we get much
better buyin from various desktops for the the icon naming spec.
The spec simply states that hicolor will always be tried, and that it
will be the last. That means that it is a good place to install
icons to, which you need to be available regardless which theme the user
selects.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
Matthias Clasen wrote:
On Mon, 2007-04-30 at 11:57 -0700, James Richard Tyrer wrote:
It is recommended that the icons installed in the hicolor theme
look neutral, since it is a fallback theme that will be used in
combination with some very different looking themes.
My reading of this is that HiColor is a fallback theme that should
contain neutral ('unthemed', generic, or whatever) icons and that
it should be a full set of icons -- if not a full set, what will
there be to fall back to?
From my perspective, the whole full theme vs fallback is a
total red
herring. A full theme is an impossibility anyway, until we get much
better buyin from various desktops for the the icon naming spec.
Obviously, there will always be some icons that are missing. That is
not the way it is supposed to be, it is a bug that needs to be fixed.
The spec simply states that hicolor will always be tried, and that it
will be the last.
Not to belabor the point, but it does say fallback and there is no point
in falling back to an empty directory.
M-W says:
fallback. noun.
1 : something on which one can fall back: RESERVE -- often used
attributively a fallback career a fallback position
You can't fall back on an empty directory -- it accomplishes nothing.
That means that it is a good place to install icons to, which you
need to be available regardless which theme the user selects.
Yes, you are absolutely correct about that. So I made the neutral,
unthemed, generic icons and installed them in HiColor. They were
removed from SVN without even consulting me. I was told that I could
install them in KDEClassic (which they are not) and they are not
available for fall back there.
--
JRT
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue (was: KDE/kdesdk)
On 4/27/07, James Richard Tyrer [EMAIL PROTECTED] wrote: As I see it, the problem is that we don't have a proper set of HiColor icons. Someone moved all the existing HiColor icons to KDEClassic and for some reason all new HiColor icons were removed. Then some HiColor icons were renamed CrystalSVG and some CrystalSVG icons were renamed HiColor. Now GNOME seems to have emulated us and removed their HiColor icons as well. To me this is a real mess. Why is this bad? Apps drop their default icons to hicolor so these are picked up regardless of the theme in use. Why should any theme put its icons there? If a theme is complete, no icons will ever need to be searched for in hicolor. If it is not complete, it should provide its own list of parent themes (e.g. based on CrystalSVG) and the missing icons shouldbe picked from the parent theme, so again, no need to search hicolor. The icon search is supposed to fall back to HiColor. The problem is that now neither KDE nor GNOME has a set of HiColor icons to fall back to. The answer to this should be obvious (and it needs to be added to the standard). We need to have a list of secondary backup icon themes that will be searched when a fall back to HiColor doesn't find an icon. I suggest that this be in a file so that it can be easily changed (or changed by the user). Why do you think a list like that would be needed? I see hicolor as a place where apps can drop their default icons so they work regardless of the theme in use. If a desktop icon theme is missing some icons and it does not provide a parent to interrogate for the missing bits, then I consider the theme to be broken, not the icon spec/desktop. Sorry if I failed to follow your way of seeing things. -- Patryk Zawadzki Generated Content ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
Patryk Zawadzki wrote: On 4/27/07, James Richard Tyrer [EMAIL PROTECTED] wrote: As I see it, the problem is that we don't have a proper set of HiColor icons. Someone moved all the existing HiColor icons to KDEClassic and for some reason all new HiColor icons were removed. Then some HiColor icons were renamed CrystalSVG and some CrystalSVG icons were renamed HiColor. Now GNOME seems to have emulated us and removed their HiColor icons as well. To me this is a real mess. Why is this bad? Apps drop their default icons to hicolor so these are picked up regardless of the theme in use. HiColor is not default, it is fallback. Why should any theme put its icons there? If a theme is complete, no icons will ever need to be searched for in hicolor. If it is not complete, it should provide its own list of parent themes (e.g. based on CrystalSVG) and the missing icons should be picked from the parent theme, so again, no need to search hicolor. While I half agree with you, the point here is the standard: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html The icon search is supposed to fall back to HiColor. The problem is that now neither KDE nor GNOME has a set of HiColor icons to fall back to. The answer to this should be obvious (and it needs to be added to the standard). We need to have a list of secondary backup icon themes that will be searched when a fall back to HiColor doesn't find an icon. I suggest that this be in a file so that it can be easily changed (or changed by the user). Why do you think a list like that would be needed? I see hicolor as a place where apps can drop their default icons so they work regardless of the theme in use. Since HiColor is no longer considered a theme, these default icons often don't exist. It will now allow an application to provide a generic set of icons which will be used (as a fallback) no matter what theme the user has selected, but it doesn't address the issue in this thread which is what should happen when an icon theme is missing icons. If a desktop icon theme is missing some icons and it does not provide a parent to interrogate for the missing bits, then I consider the theme to be broken, not the icon spec/desktop. The problem with that is that the user's Desktop knows which icon themes are installed and there is no way for an icon theme the user installs to know that. The recent changes to the icon theme spec don't change the fact that we need a generic icon theme to fallback to. Not using HiColor for this them has only further confused the issue. Since the Icon Theme Spec no longer specifies the name of this them, we need for this to be configurable. This current issue illustrated the need for this. -- JRT ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [kde-artists] Icon naming issue
Kenneth Wimer wrote: You say yourself that icon themes will never be complete...so the hicolor theme you desire also fails in this way...not sure what you want exactly. Yes, a complete icon set should never be presumed, that is why I have clearly stated that there needs to be a way to configure multiple fall backs. Multiple fall backs are to be provided based on the theory that some icon is better than having no icon (or the unknown icon). If HiColor is to be a theme, then these additional fall backs should come after HiColor, but if it is to be used only for miscellaneous icons that are installed by apps, then these multiple fall backs can come before HiColor as the spec says. What I want is for this to be configurable and not hard coded. If your position is that this should not be hard coded, please defend it. If a desktop icon theme is missing some icons and it does not provide a parent to interrogate for the missing bits, then I consider the theme to be broken, not the icon spec/desktop. The problem with that is that the user's Desktop knows which icon themes are installed and there is no way for an icon theme the user installs to know that. The recent changes to the icon theme spec don't change the fact that we need a generic icon theme to fallback to. Not using HiColor for this them has only further confused the issue. Since the Icon Theme Spec no longer specifies the name of this them, we need for this to be configurable. This current issue illustrated the need for this. The answer, as I see it, would be to do as kde has done and to fallback to the desktop default theme. This proved to be very unsatisfactory since CrystalSVG icons looked very out of place in almost all other icon themes that were not Crystal type. Others have complained loudly that they don't want CrystalSVG icons dropped into a DeskTop with Oxygen icons. They are correct about this issue. However, that issue is a general issue that needs to be addressed for all icon themes that a user might install. Part of this issue was a bug; it did NOT fall back to the default theme as indicated by the link: default, it fell back to CrystalSVG and this was hard coded. The link: default was redundant since it could not be changed to point to another icon them. This was a choice of the desktop in question and there are good arguments for this, I have previously stated. Having bugs in the system is not a choice of the desktop, and hard coding an icon theme is a very bad choice. It should work correctly so it is possible for a user to choose a theme other than the default. Last time that I tried, if you change the default.kde link to point to something other than crystalsvg KDE won't even start. Perhaps this bug has now been fixed. In earlier kde's this was crystal, in newer versions it would be oxygen - the point that you disagree with so much. A desktop pics a default theme for a good reason. If you do not like that choice you are surely free to build your own system which does exactly as you like. If a DeskTop picks a default icon them for the reason of forcing everyone to use it, as appeared to be the case with CrystalSVG, this most definitely NOT a good reason. To say that everyone that doesn't like the default theme should build their own system is the height of arrogance. Does this also include visually impaired users? Perhaps you should post to KDElook that people should stop making other icon themes. Visually impaired users should pick a theme according to their needs. Ideally the install routine should include an option for these users to get the icon theme they need after install but this is not an issue of this list (at least not yet). You are, I hope, aware that if a user picks a theme according to their needs and the needed icon isn't available in the needed size that they get instead a CrystalSVG icon and there is no way to fix this using the Control Center. What is needed is for KDE to work correctly according to the spec, and for all icon themes to be equal (and one of them specified as default) with the exception of the HiColor fall back. If you don't know what I mean by this, it means that if you select (for example) KDEClassic that the code shouldn't drop CrystalSVG icon onto your DeskTop without being asked to do so. The default icon theme should be the same as any other default; the user should be able to easily change it by using the Control Center. But as the spec clearly says hicolor is only a place for apps to install their icons. I believe that you have added the word only. And (surprise) it still says: q It is recommended that the icons installed in the hicolor theme look neutral, since it is a fallback theme that will be used in combination with some very different looking themes. /q So, a generic icon theme /could/ be installed in HiColor. I still think that this is the best idea, but there might be conflicts with apps installing
