Multiple DeskTops, HiColor theme, standardized icon names, &menu icons
James Richard Tyrer
tyrerj at acm.org
Sat Jul 1 01:02:08 EEST 2006
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
> 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
> 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).
More information about the xdg