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

List:       kde-commits
Subject:    Re: kdelibs/kio
From:       Rolf Magnus <ramagnus () zvw ! de>
Date:       2001-11-09 1:04:59
[Download RAW message or body]

On Monday 05 November 2001 13:45, Carsten Pfeiffer wrote:

> >  > Well, then those views have to decide what to show, not the other way
> >  > round, IMHO.
> >
> >  That's what I also think, but in this case the view needs to explicitly
> >  support all mimetypes that have a plugin.
>
> Hmm?

If the view wants to explicitly ask for the items to show, it needs to know 
which ones it should request for a specific mimetype. So the view needs to 
know about every supported mimetype. But I think the best is to use priority 
sorting (like in the tool tip) by default and then let the user change it if 
he wants.

> If you need more than just a string, you could make the map QString ->
> KMetaData or something like that.

Then I still need the priorities, which could instead be the index of an 
array. Searching for a specific key in it isn't a problem. I'm thinking of 
making an own class for the list and having operators like this for the 
lookup:

KMetaInfoItem& KMetaInfo::operator[] (const QString& key)
and
KMetaInfoItem& KMetaInfo::operator[] (const int& index)

Then I can iterate over e.g. the first 5 ones with a for loop, or I can ask 
for an item by key name.

> >  Hmm, and what happens if the user changes his language settings? And
> > also,
>
> I don't see the problem, but you're right, looking up with translated
> strings is a bad idea. Ok, so the plugin has to offer both the translated
> and untranslated key. The GUI can display the translation, but the lookup
> is done via the untranslated one.

That's exactly what I want to do.

> Yes. Simply ask the PluginManager if e.g. "Author" is supported (i.e. a
> plugin that can serve this is available) and there you go.

Hm? Does this mean you think more than one plugin for a mimetype should be 
possible? I was thinking of having one plugin per mimetye.

> Hmm, I don't think the plugin should decide the priority. It's actually
> plugin-independent, but key-dependent. I.e. you don't want the id3-tag
> plugin to give a priority 5 to "author" and the kword-plugin a priority 3
> to "author". Or would you want that?

Maybe. If I know I wrote all the kword files on my PC, I'm not interested in 
it, whereas the mp3 author (which btw. is not called author but artist in 
id3) still may be of interest.

I would like to avoid assumptions on what keys may exist for a given mimetype, 
or even for a given file as much as possible. There are even some file 
formats that have keys that can be defined freely in the file, like ogg and 
png, which both have a list of key/value pairs that can contain anything.

> There is the list of supported keys and the user could arrange that list in
> a nice GUI, setting up his preferrence order. Then the PluginManager could
> have a method
> KMetaData preferredItems( int howMany )
> That way, you don't even have the problem of sorting the map. The manager
> knows the preferred items and simply returns those.

Having those lookup operators above, this might not be neccessary, but I could 
add this, just in case there is a plugin that is faster if only the "most 
preferred" items are to be read.

> Hmmmm, someone talked about adding a kio_find or something like that
> (basically kquery.cpp from kfind), which returns a KFileItemList. That
> could be used in kfile easily. That would be pretty cool, IMHO.

I'll look at this later. So kio_find would be just another kioslave that 
returns a list of the files that were found?
So an url like find:*.mp3&Artist=Madonna would produce a list of all Madonna 
mp3s?

Perhaps we should talk on irc about that. Since it's the first addition I 
would make to kdelibs, I don't want to make it wrong. I already made header 
files (even including docs) from the ideas I had, but destroyed them with 
cvs-clean. At least I learned something from this :)

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