Version: (using KDE KDE 3.2.3) Installed from: Debian testing/unstable Packages OS: Linux Currently there is no way for a user to choose through user interface what program they want to use to handle a URL scheme. For example, nowadays both KPlayer and KMPlayer come with mms.protocol, pnm.protocol and rtsp.protocol files, that are installed into share/services. The last one to be installed overwrites the existing one and so takes precedence. I think there needs to be a way to keep a list of programs capable of handling a URL scheme, and allow the user to choose through the GUI which of those programs they want to use to handle each URL scheme. This should have an interface similar to File Associations in Konqueror. For example, the list for rtsp:// URLs would include KPlayer, KMPlayer, Kaffeine, MPlayer, RealPlayer, HelixPlayer and so on. Currently the user has to reinstall the program of choice so it overwrites the share/services/rtsp.protocol file, or edit it manually.
Yes, I agree, we probably shouldn't be using protocol files for this but map it to a mimetype instead and then it can be configured via the file type associations. I suggest to deprecate the Exec field in .protocol files and if a .protocol file with Exec field is encountered or if no .protocol file is found, we should do a trader query for something like "uri/protocol" and if that gives any hits, use that instead.
Could we please add this to the 3.4 feature plan? Thanks!
CVS commit by waba: If a helper-protocol has an empty exec line we find an application using the default mimetype. CCBUG: 84664 M +6 -1 krun.cpp 1.260 --- kdelibs/kio/kio/krun.cpp #1.259:1.260 @@ -384,5 +384,5 @@ QStringList KRun::processDesktopExec(con if( !mx1.hasUrls ) { for( KURL::List::ConstIterator it = _urls.begin(); it != _urls.end(); ++it ) - if ( !(*it).isLocalFile() ) { + if ( !(*it).isLocalFile() && !KProtocolInfo::isHelperProtocol(*it) ) { // We need to run the app through kioexec result << "kioexec" << exec; @@ -795,4 +795,9 @@ void KRun::init() { exec = KProtocolInfo::exec( m_strURL.protocol() ); + if (exec.isEmpty()) + { + foundMimeType(KProtocolInfo::defaultMimetype(m_strURL)); + return; + } run( exec, urls ); ok = true;
Ok, for KDE 3.4 I would like to change mms.protocol in kdelibs/kio to include: helper=true exec= defaultMimetype=uri/mms and then kmplayer should no longer install mms.protocol but list uri/mms as a supported mimetype instead. I guess I should also add a uri/mms.desktop file to define that as a mimetype then. Likewise for rstp and pnm.
Hi Waldo: Your patch is clearly a step in the right direction. However, please consider this: What if we look at uri/<protocol> mimetype _first_, and if there are registered handlers, use the top one. Then the exec= field would only be used when there are no registered handlers. The advantages of this I can see: - it will work even if existing packages install their own .protocol files with whatever exec= fields; and there are already a bunch of them that do that; - it will allow each user configure their own handlers, again regardless of whether the exec= field is empty or not; at least some of the existing packages install their .protocol files into the global share/services. - it will be backwards compatible, and will work when only legacy (pre-3.4) protocol handlers/helpers are installed. Can you think of any disadvantages? Thanks a lot! -- kiriuja
Created attachment 9181 [details] Patch for .protocol files The mms.protocol file still does not have the changes you suggested. Also, the rtsp.protocol file has non-empty exec= field pointing to realplay, which imho is pretty bad nonsense, since realplay does not ship with KDE, is not a KDE program, and is not Free Software. Attached patch corrects both .protocol files. Could you please apply it before the 3.4 release? Thank you! Also, there should be pnm.protocol, mmst.protocol, mmsu.protocol, rtspt.protocol and rtspu.protocol files with similar content.
Re #5: Yes, I agree that that would be nice, unfortunately that approach doesn't fit very well in the current code. Re #6: I don't want to change rtsp.protocol like that because it would break existing reaplayer setups: existing reaplayer.desktop files don't list uri/rtsp as a supported mimetype. I could perhaps use application/vnd.rn-realmedia (or something like that) as default mimetype, since it already supports that. I would need to know if that particular mimetype would be a good choice though.
Most common mime for real, in my experience, is audio/x-pn-realaudio. Strangely enough also for video.
CVS commit by vriezen: Don't install protocol files for KDE > 3.3.90 (based on mlaurent's fix for 3.1 mimetype) CCBUG: 84664 M +4 -0 ChangeLog 1.41 M +5 -1 Makefile.am 1.4 M +12 -0 configure.in.in 1.42 M +1 -1 src/kmplayerconfig.cpp 1.113 --- kdeextragear-2/kmplayer/ChangeLog #1.40:1.41 @@ -1,3 +1,7 @@ Changes since version 0.8.4-rc5 +- Controlpanel uses paletteForegroundColor for drawing +- Added a volume control to controlpanel that let backends control the volume + (unlike the slider in menu, which uses kmix) + two actions for shortcut + possibility in 'Configure Shortcuts' dialog - Bookmarking a VDR channel now bookmarks it as kmplayer://vdrsource/channel - When controlpanel is in autohide mode, move it over the video instead of --- kdeextragear-2/kmplayer/Makefile.am #1.3:1.4 @@ -1,3 +1,7 @@ -SUBDIRS = mimetypes protocols src icons +if need_kde33_compatibility + KDE33PROTOCOLS = protocols +endif + +SUBDIRS = mimetypes $(KDE33PROTOCOLS) src icons EXTRA_DIST = AUTHORS COPYING ChangeLog INSTALL README TODO kmplayer.lsm --- kdeextragear-2/kmplayer/configure.in.in #1.41:1.42 @@ -165,4 +165,15 @@ AC_COMPILE_IFELSE([ #include <kdeversion.h> +#if ! ( KDE_IS_VERSION( 3, 3, 91 ) ) +#error KDE 3.3 +#endif +], + need_kde33_compat="no" +, + need_kde33_compat="yes" +) + +AC_COMPILE_IFELSE([ +#include <kdeversion.h> #if ! ( KDE_IS_VERSION( 3, 2, 90 ) ) #error KDE 3.2 @@ -197,4 +208,5 @@ fi +AM_CONDITIONAL(need_kde33_compatibility, test "$need_kde33_compat" = "yes") AM_CONDITIONAL(need_kde32_compatibility, test "$need_kde32_compat" = "yes") AM_CONDITIONAL(need_kde31_compatibility, test "$need_kde31_compat" = "yes") --- kdeextragear-2/kmplayer/src/kmplayerconfig.cpp #1.112:1.113 @@ -161,5 +161,5 @@ KDE_NO_EXPORT void Settings::readConfig urllist = m_config->readListEntry (strURLList, ';'); sub_urllist = m_config->readListEntry (strSubURLList, ';'); - volume = m_config->readNumEntry (strVolume, 0); + volume = m_config->readNumEntry (strVolume, 80); contrast = m_config->readNumEntry (strContrast, 0); brightness = m_config->readNumEntry (strBrightness, 0);
Created attachment 9193 [details] Patch for .protocol files Hi Waldo: Just saw your commit of the protocol files. Basically, it should solve the problem. One minor thing for you guys to consider: I thought that maybe using an application MIME type as opposed to audio or video could help avoid confusion, since there is no easy way to know if a file will have a video component. Because we are trying to keep backwards compatibility, any MIME type that is associated with RealPlayer by default will work equally well, so the attached patch changes it to application/vnd.rn-realmedia for all RealMedia URLs: rtsp, rtspt, rtspu and pnm. Also, I thought we might as well use application/x-mplayer2 for mms* URLs and so do away with the whole uri/* business altogether. A minor downside would be that the seven files would point to only two different MIME types, one for RealMedia and the other for Windows Media, but that is what the user will want most of the time anyway. What do you think?
Koos, any opinion on the last two paragraphs of comment #10 ?
I don't see how that would improve the uri/protocol way. It would seem like magic changing application/x-mplayer2 assoc. changes mms too (btw. kdelibs doesn't have that mimetype). Since there is no way to choose a protocol handler before your patch (hey, that's the subject of this BR), I guess it would loose functionality to go for the #10. However the uri/protocol might not be the most user friendly way to do this. Also choosing handlers for eg. tar and friends would be nice to be configurable. Until that happens, I would keep it as-is. (BTW, is this an issue for fd.o standards?)
This is really a tradeoff between flexibility and usability. If we have the seven .protocol files each pointing to its own mime type under uri/*, the user will have flexibility to point each one of them to a different program, plus of course they will be able to choose standalone handler and embedded handler separately. On the other hand, if they want to switch all seven protocols from one program to another, they would have to make that change exactly 14 times. More flexibility -> less usability. If we have rtsp, rtspt, rtspu and pnm all pointing to application/vnd.rn-realmedia, and mms, mmst and mmsu all pointing to application/x-mplayer2, the user will have to make a change in only four places when switching from one program to another. Who knows, maybe for some obscure reason someone will want to handle rtsp with one program and pnm with another, but that is not likely imho. So, more usability -> less flexibility. Plus, without uri/* the file association tree will be one branch shorter -> less clutter in the UI. And of course it will still be possible to choose through the UI what program handles rtsp, pnm and mms, so the purpose of this bug report is satisfied. Koos is right in that application/x-mplayer2.desktop would have to be moved from extragear-2/kmplayer to kdelibs -> more work for developers, yes. In this particular case I vote usability. But whatever you guys decide in the end is fine with me.
Considered fixed