[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: icons in the new FSSTD. PROBLEM !
From:       Christoph Neerfeld <Christoph.Neerfeld () bonn ! netsurf ! de>
Date:       1997-09-09 11:33:18
[Download RAW message or body]


On 08-Sep-97 Stephan Kulow wrote:
>> 
>> On 08-Sep-97 Stephan Kulow wrote:
>> 
>> >$KDEDIR/share/icons shouldn't be in the searchpath. It's only for kfm
>> >and kpanel.
>> 
>> and kmenuedit and ktaskbar. Having this directory not in the searchpath
>> means different kiconloader handling for these apps which is possible 
>> but not desirable.
>> 
>> We have to decide on this, because I'd like to send a new version
>> of kiconloader to Kalle.
>> 
>> My current solution is:
>> 
>> [KDE SETUP] IconPath=...
>> $KDEDIR/share/icons
>> $KDEDIR/share/toolbar
>> $KDEDIR/share/apps/<appName>/toolbar
>> $KDEDIR/share/apps/<appName>/pics
>> $HOME/.kde/icons
>> 
>> The last one is necessary for user defined kdelnk-files.
>> 
>> If $KDEDIR/share/icons is not in the searchpath, then kfm, kpanel,... need
>> to take care of this directory and $HOME/.kde/icons and any direktory in
>> [KDE Setup] IconPath themselves. I realy dislike this idea.
>> 
>> I think it is better to take care that $KDEDIR/share/icons and $KDEDIR/share/toolbar
>> do not contain icons with the same name.
>
>Why will you hard code this paths anyway. Why not hard code the paths, that
>every application will use and add a appendSearchPaths to allow kpanel etc.
>to extend them? You must think of several applications, that want to use
>KIConLoader only to search toolbar pixmaps.

I thought about this myself and I can implement it. Well, I think I will.
But this does not solve the problem. If kpanel appends this path by itself, it will
suffer from the same problem because it has the full searchpath.


-- Chris.
>
>Greets, Stephan


--------------------------------------------------------------
Christoph Neerfeld <Christoph.Neerfeld@bonn.netsurf.de>

[prev in list] [next in list] [prev in thread] [next in thread]