This is a discussion on Re: How to debug kioslave problems ? [Was: Problem opening - KDE ; > On Tuesday 04 April 2006 23:34, Pavel Troller wrote: > > Now, when I try to open a device, which is > > shown by the slave, it pops up an "Save/Open with:" dialog, instead of opening > > ...
> On Tuesday 04 April 2006 23:34, Pavel Troller wrote:
> > Now, when I try to open a device, which is
> > shown by the slave, it pops up an "Save/Open with:" dialog, instead of opening
> > it automatically by another slave (sdp:/).
> This slave is returning items with another protocol in UDS_URL than the slave's own protocol...
> I'm not sure this is really supported... I thought one had to use redirections or ForwardingSlaveBase
> for this kind of thing, but well; this is I think unrelated to the problem you're describing,
> so we can always come back to this one later if needed
> (should mostly be a problem in treeviews; for flat icon/list views it might work fine).
> createDirEntry(entry, devName,
> DeviceClassMimeConverter::classToMimeType(devClass ));
> Showing 'open with' seems to tell me that the mimetype is wrong;
> what's the mimetype being passed in the above call?
It's shown as either "Phone Bluetooth Device" (for phones) or "Miscellaneous Bluetooth device"
(for computers including localhost). I've found their .desktop files, they are in
kdebluetooth-common/mimetypes in the kdeextragear-pim package and the exact type is
bluetooth/phone-device-class and bluetooth/misc-device-class.
I've tried to replace the above with generic "inode/directory" in createDirEntry(). It
solved the Open with: problem, but all the items were of course shown as folders; normally
they are shown either as a phone handset or as the bluetooth symbol.
I've also proactively looked at another .desktop files (for example, in "media" directory)
and I've found a line there saying "X-KDE-IsAlso=inode/directory". I've tried to put this
line to the appropriate desktop files, and... it helped :-)! No more "Save/Open As:", but
direct open in the same konq window, as it used to be!
> Hmm, this url thing does seem weird. A redirection might solve this,
> which you could try by
> 1) removing the UDS_URL atom
> 2) catching such items in listDir() - which currently only supports listing "/", i.e. bluetooth:/
> and calling redirect(newurl) from there, where the newurl is the one that used to be in UDS_URL.
> This means somehow finding the new url from listDir, I'm not sure what's the best way to do that
> in that code, it means getting the name and class again, a bit like in doListBrowse but
> preferrably without iteration...
Do you think that this is really necessary, when the "X-KDE-IsAlso" trick works ? It looks
to me as a relatively major code change; I would like the author/current maintainer of
kdebluetooth to do it... If there is any... It seems that the package has been abandoned,
which is really wrong...
OK. I will try to clean up the things, solve the rest (there are still some problems
with sdp:// "More services" directory) and then create a patch.
With regards, Pavel Troller
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<