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

List:       kde-core-devel
Subject:    Re: Part loading where mimetype won't work and KIO filters.
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-03-27 23:55:57
[Download RAW message or body]

#if Martijn Klingens
> On Tuesday 27 March 2001 16:19, Rik Hemsley wrote:
> > 1.
> >
> > I'd like to have a KPart loaded when audiocd:/ is requested. I can't
> > do this based on mimetype because audiocd:/ has a type of 'directory'.
> 
> You might want to read the thread on kde-devel about directory mimetypes ;-) 
> It was suggested to create specialized mimetypes like inode/audiocd-directory 
> that inherits inode/directory. In that case you can load the part based on 
> the mime type ...

Yes, I just read that and it seems like the perfect solution. I had
assumed that if I reported inode/audiocd-directory then I would break
apps that wanted to treat it as inode/directory. This way, I can be
compatible.

> > Is there a way to load a part based on URL ?
> 
> Might still be useful to have, though (if it's not already there)

Yes... but I like the mimetype inheritance trick better :)

> > The other tricky part is that the part must not be loaded if a filename
> > is specified, e.g. audiocd:/track01.wav
> 
> But doesn't the file have another mime type than the cd itself? How could 
> both spawn the same part then?

I was thinking that if parts were loaded based on protocol then
it would load my part for files too, not just the directory. It
wouldn't be able to tell the difference between a file and a directory
without asking the slave, because of the crazy situation where
http://www.kde.org/blah == http://www.kde.org/blah/ where blah
is a directory.

But... that's not a problem if I use the mimetype inheritance thing.

Thanks to all who replied. I thought I was stuck ! :)

Rik

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