From kde-core-devel Wed Oct 10 21:40:21 2001 From: Bernd Gehrmann Date: Wed, 10 Oct 2001 21:40:21 +0000 To: kde-core-devel Subject: Re: KIO patch X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100275012303278 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.