Patches item #1301512, was opened at 2005-09-23 17:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:47 Message: Logged In: YES user_id=261020 Looking at the thread you reference, I guess it would be nice if the desktop module supported returning a process handle. On Windows, I imagine os.startfile could be extended in Python 2.5 to use StartFileEx() (win32 function suggested by Thomas Heller) and return a process handle. I guess it's worth asking whether that's actually very useful without ctypes or win32all, though. Anybody know how you'd get a pid out of KDE or GNOME? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:28 Message: Logged In: YES user_id=261020 I guess there are probably security implications with using kfmclient exec (risk of running arbitrary code)... but then I guess the same applies to os.startfile(). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-24 13:13 Message: Logged In: YES user_id=261020 +1 on the idea, but a slight change to the implementation for KDE... I wrote a detailed bug report below, then discovered the solution to what I assume is a bug. Here's the solution: For KDE, use 'exec' instead of 'openURL' as the first argument to kfmclient. Here's the detailed report: I tried setting up KDE 3.2.2 to associate text files in the order: Emacs KWrite KEdit Kate I used Control Center->KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
