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

List:       kde-devel
Subject:    Re: kpixmapcache vs kiconloader
From:       Stephan Kulow <coolo () itm ! mu-luebeck ! de>
Date:       1999-05-26 9:48:53
[Download RAW message or body]

David Faure wrote:
> 
> On Tue, May 25, 1999 at 10:08:42PM +0200, Stephan Kulow wrote:
> > David Faure wrote:
> > >
> > > On Tue, May 25, 1999 at 09:28:16PM +0200, Stephan Kulow wrote:
> > > > Hi!
> > > >
> > > > As far as I can see, both do almost the same. Is there a
> > > > reason for Kpixmapcache or can it be merged into kiconloader?
> > >
> > > I first thought that they should be merged (which means that kiconloader would get
> > > all the additional methods that exist in kpixmapcache).
> > > BUT : this would mean that the result of the merge would have
> > > to be in kio, because it uses the mimetype stuff !
> > > (e.g. pixmapForURL(...), pixmapForMimeType(...))
> > > => in fact I see no way of merging.
> > >
> > > We don't want all apps that use the icon loader to be required to link to kio...
> > > The same problem ever and ever again....
> > >
> > > The only thing that could be removed from kpixmapcache are toolbarPixmap and wallpaperPixmap.
> >
> > Then I propose to make class kiopixmapcache : public kiconloader
> 
> Great idea.
> 
> > Will look into it.
> 
> Cool.
> 
> The kstddirs methods have a limitation : as they don't handle mini icons,
> I don't see how to port ktop. It used to iterate over all files in kde_icondir() + "/mini".
> findAllResources does the job of iterating, but it doesn't handle mini icons.
> What's the solution ?
> 
The solution is to add the resourceType mini in kstddirs. I thought I
could
live without it, but I can't as kmenuedit shows too.

Will fix that asap. After that you can just use findAllResources("mini")

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online

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