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

List:       kde-core-devel
Subject:    Re: KIO patch
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-10-10 21:55:00
[Download RAW message or body]

> Another thing I noticed now is that it is possible to add context menu
> items for mime types this way.
Yes, well, that's what I was talking about ;)

> But there is an additional possibility
> to do this by installing a desktop-like file in servicemenus. Any reason
> for this duplication. 
Servicemenus are very konqueror-specific (and kdesktop).
An application using KTrader to get hold of the applications associated
with a mimetype will get the "allow-as-default=false" applications in the
result, but it won't get the servicemenus.

> BTW, it seems that this context menu is not only
> added for files with the respective mime type, but also for the .desktop
> file itself. For example, if I point Konqueror to kdeutils/ark and click
> the right mouse button over arkservicemenu.desktop, it offers me to
> extract the file arkservicemenu.desktop... this doesn't seem right :-)
Bugs......

> > That doesn't matter. The servicetype Application is implicit for Type=Application
> > files anyway. So it's always there, whether explicitely or implicitely.
> > (The goal of that, is to automatically get all properties for an application,
> > see kdelibs/kio/application.desktop)
> 
> Hmm, I'll never understand why mime types are called service types in
> some contexts :-/
After you read all this, and wrote so much docu about it !!?? ;)
Service types are a more generic notion than mimetypes.
Compare
"what are the applications handling text/html"
with
"what are the read-only parts in KDE"

The first one asks for the applications handling a mimetype (specific case)
the second one asks for the services (e.g. parts) handling a servicetype (called KParts/ReadOnlyPart).
The mechanism is the same, but can you say that KParts/ReadOnlyPart is a mimetype ? 
Is't not, since it doesn't relate to the type of some files.

So an application is a particular case of a service (one that is described
by a Type=Application .desktop file, as opposed to general services which have
Type=Service),
and a mimetype is a particular case of a servicetype (one that is related to
the type of a file). MIME-types are a type of file... Service-types are a type of... service ;)

> Anyway, I thought that Type=Application files are meant
> to achieve some interoperability, and somehow I doubt that anyone except
> for KDE knows about a mime type "Application".
Of course not, since it's a servicetype, not a mimetype ;)
As I said, this is quite internal, it allows to use the mechanism of "grab the
available properties for a servicetype, from the servicetype's desktop file",
to declare the properties for Applications.
But you're right, no application cares about that explicitely, it's handled
by KIO itself.

> > Cool. Well, please drop me a mail (or mention in the cvs log) when it's finished :)
> 
> Ok, I think they are complete enough for a first approximation. At least
> it's IMO more useful than the sparse information in the header files...
Yes, thanks much for your work on this.
I'll have a look whenever I can :}

> Speaking of header files, what about moving ProgressBase and friends into
> the KIO namespace? Also, hmmmmm, their header files are installed twice in
> different directories. One should be enough, shouldn't it? ;-) 
That's probably a compatibility issue, feel free to fix and cleanup.

> Then there is ktypecode.h which is not used at all 
Right, please remove, it has been replaced by ksycocatype.h

> and uiserver.h which is not part
> of the API but of a separate executable. 
Hmm, so ? We need this interface to be declared and publically available,
libkonq needs it to generate the DCOP stubs needed to contact the UIServer.
So it's part of the API, in a way.

> And it seems uiserver.stub
> doesn't have to be linked into libkio..
Then how would a Job's Observer contact the UIServer ?
I think we need this.

David.

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