[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-01 2:25:56
[Download RAW message or body]

On Tuesday 30 October 2001 15:35, 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.

> It could show the first 5, no? You might have to implement an operator>()
> and operator<() for QString to achieve a priority sorting in the map,
> instead of alphabetical sorting.

Or the plugin could just return an array instead of a map. One could still 
search for specific fields there. And I want to include one string to search 
for, which is the untranslated key, and also the translated one as a separate 
string. This would solve the translation problem (see below). I also want to 
give the fields more attributes than just a value (for example a bool that 
tells if the field is editable). and the fields should have a type, which 
would also be good for editing (maybe even a QRegExp that describes the 
allowed values). Then, another method can be added to the plugin that can 
change some fields of the metadata.

> Ok, how does it work in Konq's listview for example:
> - you configure "show me Name, Author, Date, Title" in the listview.
> -> the view queries the fileitems for exactly those fields (translated or
> not) - question: where does it get the available fields? per mimetype or
> all? -> plugins know which fields they support and the plugin managing
> class knows which plugins are available. So the plugins need to ship
> translated .desktop files with the fields they support (otherwise new
> plugins could never add new translated fields).
> -> so the listview asks the plugin manager which fields it has to offer,
> offers that list to the user and creates columns for the user's selection
> -> then it can simply ask for the data for every column, using the
> translated field as key.

Hmm, and what happens if the user changes his language settings? And also, the 
listview should have defaults so that the user doesn't need to specify all 
the fields he wants to see for every mimetype.

> Other "view", like a tooltip or a property dialog can simply show a subset
> of all metadata, using just the first xxx items from the map (if the map
> can be sorted by some priority (who would decide that?).

This would be ok I think. The plugin itself, or its programmer, can decide on 
the priority. This could also be made configurable through the .desktop file 
later without breaking anything if it's really needed.

> Ideally, the properties dialog should even make them writable, if possible.
> E.g. if file->isReadable() -> offer a lineedit for every editable meta data
> field :) But that can wait a little, I guess ;) Maybe add a virtual method
> to the plugin baseclass writeMetaData( const QString&, const QString& ) so
> that we could add it later without breaking BC..

Yes. ATM, I think I should add only the parts that break BC. Then, afterwards, 
all the "visible" features that depend on it can still be added in KDE 3.1. 
Someone also suggested to add an option to the file search dialog to search 
for metadata contents, but I first have to try if this makes sense wrt the 
time needed for such a search.

> > metadata. And I still would like to have a class that could get the
> > information for one file without running through kio.
>
> That would only mean making the plugin-loading mechanism a separate class,
> no?

Yes, that's what I wanna do.

Btw: I recently had to use windows XP (though I don't like windows at all), 
and I noticed that its file viewer has almost exactly what I would like to 
add to konqi.

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