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

List:       kde-core-devel
Subject:    Re: KIO patch
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       2001-10-10 21:40:21
[Download RAW message or body]

On Sat, 6 Oct 2001, David Faure wrote:
> > Well, not exactly, that's why I'm asking :-) AFAICT, the allowAsDefault
> > in KServiceOffer is an AND between the value in the .desktop file and
> > the value in profilerc. But the latter is always TRUE...
> 
> Ok, then that's for a possible future feature of being able to set it to false
> in the profile. Not really useful though, I'd agree.

Another thing I noticed now is that it is possible to add context menu
items for mime types this way. But there is an additional possibility
to do this by installing a desktop-like file in servicemenus. Any reason
for this duplication. 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 :-)

> 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 :-/ 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". Well, it probably doesn't
hurt...

> > See mime.html in the kde2arch section on developer.kde.org. Would be
> > nice if someone would proofread this and services.html, when it's
> > finished.
> 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...

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? ;-) Then there
is ktypecode.h which is not used at all and uiserver.h which is not part
of the API but of a separate executable. And it seems uiserver.stub
doesn't have to be linked into libkio.

Bernd.

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