Multiple DeskTops, HiColor theme, standardized icon names, &menu icons

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Friday 30 June 2006 13:24, James Richard Tyrer wrote:
>> I proceed on the valid theory that the lack of standards also imposes a
>> price on third party applications.  Such applications have to install
>> their icons somewhere.  In some cases they must install them in multiple
>> locations to try to comply with the methods of multiple
>> DeskTops/ToolKits.
> 
> which app uses multiple toolkits to load icons today?

I believe that the purpose of Portland and XDG standards is for *future* 
cross DeskTop/ToolKit compatibility.  Obviously, there may be nothing 
_today_ because the standards which would make it possible don't exist yet.

> which kind of app would want to use multiple toolkits to load icons?

Obviously, a third party app which did not use either KDE or GNOME for 
its ToolKit and used Portland to access functions to load icons would 
need a standard location to install such icons.  IIC, the Portland 
manifesto advocates a common interface for third party apps to access 
such functions which would not be dependent on the DeskTop that it was 
being run with.

So, the answer is: a third party application that loaded icons by 
accessing the DeskTop's ToolKit through Portland library functions (IIUC 
a wrapper of sorts).

>> If a third party application is going to access services through
>> Portland, it should be obvious that cross DeskTop standards are going to
>> be needed for everything that Portland is going to provide such services
>> for.
> 
> correct. which doesn't include app private icons. =)

You have provided no reason why this shouldn't include (theme-able) 
private icons, and I believe that others have provided reasons that it 
should.  Perhaps someone in the Portland project could provide some 
official input on this.

On the surface of it, it would seem rather clumsy for an app that was 
using Portland for its global icons to have to handle its private 
(theme-able) icons in a different manner (since there is no way to 
determine if a theme-able icons is private or global without looking!!). 
  IIUC, KDE apps don't work that way.  KDE apps don't have to worry 
about whether a (properly installed) icon is global or local, the 
KIconLoader just finds it (looking first for a private icon and then for 
a global icon).

-- 
JRT