This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mwm
Date 2005-09-26.02:25:09
SpamBayes Score
Marked as misclassified
Logged In: YES 

Actually, the guess that the module makes is which desktop
the user is on - and that's overridable by the "desktop"
argument. The pre-OPENER version of had no way to
override it's choice of opener - the best you can do is tell
it to use the default opener for some desktop it knows
about. Further, the "desktop" argument is really only
applicable to the application developer. The end-user - the
person who actually chooses the launcher to use - can't use
it without editing the source to the application. While you
may consider this an acceptable configuration mechanism, I

The standard Unix mechanism for setting things like this -
dating back to the 70s - is an environment variable that
names the command to use. If you want to suggest a better
mechanism, feel free to do so. Until then the question is
what the name should be. Based on what the freedesktop talk,
maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the
other hand, the freedesktop folks seem much better at
generating discussion than specifications - and neither of
those carries as much weight with me  as running code.

Part of this does depend on the point of the desktop module.
I thought it was to make os.startfile functionality
available in a platform-independent manner. If so, it needs
to deal with things other than the tools provided by a
couple of common desktops. If instead it's supposed to
provide access to the knowledge built into the most popular
desktops, then ignoring user preferences is reasonable. But
that makes it much less usefull.
Date User Action Args
2007-08-23 15:44:00adminlinkissue1301512 messages
2007-08-23 15:44:00admincreate