New KIO::Slave: x-kde-icon

[Lauri Watts]

Frerich Raabe said:
> On Monday 21 June 2004 21:30, Marc Mutz wrote:
>> The problem:
>>
>>   When trying to write a decent handbook for a KDE app, you sooner or
>> later
>>   stumble across the icon-issue. You would like to include the icons in
>> the
>>   description of the menu item, or button, but you are faced with two
>> daunting tasks:
>>     1. Find the icons and copy them to the module/doc/app directory
>>     2. Maintain this sh*t when the icons change.
>>   Apart from that, the next icon theme makes the icons worthless. Even
>> if
>> it was only installed locally.
>
> I agree that this is a problem.
>
>> The solution:
>>
>>   A kde-icon kioslave.
>
> I think this is overengineered. Why not simply use a placeholder in the
> docbook files, an entity as in
>
> <imagedata fileref="&kde.icondir;fileopen.png"/>
>
> Then, simply create a tiny file with one entity declaration at configure
> time
> - and &kde.icondir; expands to the directory where the actual icons of the
> application are stored. Include that file in kde-chunk.xsl, and then you
> would have solved the "duplicate icons" problem as well, no?

Well, this is the thing I've been wrestling with over it - there isn't a
single kde icon directory, since any app can have it's own prefix, and any
future prefixes aren't known at kdelibs compile time (when the xslt would
have to be altered.)

It's pretty trivial to do as you say to get the icons installed by kdelibs
(and we could probably rely on kdebase ones being in the same place, but
I'm not sure even that's written in stone), and there isn't really an
elegant fallback method if you try an image and the file isn't there. 
It's really the non-standard icons (ie, the ones provided by the
application itself) that most need explaining, and most benefit from being
shown in the documentation, and they are the very ones it's so hard to
nail the path on.

The only problem this doesn't solve, is what to do for the website
(docs.kde.org, and for those authors putting their docs on other websites)

We already work around that using a different stylesheet for the websites
which uses a full path for the banner graphics rather than the help:/
kioslave the way khelpcenter does.  To deal with this the same way though,
would require a KDE installation on the webserver, which I'm pretty sure
is not a possibility.  There's almost certainly some xslt magic that can
deal with this though, so I don't think it's any reason to not use this
new kioslave.  At worst, it means two imageobjects in the docbook so there
can be a fallback.

-- 
Lauri Watts