Detecting OS and Window Manager

Jim jbublitzNO at SPAMnwinternet.com
Sat Jun 8 13:02:54 EDT 2002


Jim Richardson wrote:
> On Fri, 07 Jun 2002 00:34:30 +0100,
>  Darren Winsper <dw133 at cs.york.ac.uk.go.away> wrote:
>>In <mailman.1023304388.9659.python-list at python.org>, Sean 'Shaleh' Perry
>>wrote:

>>>the only fool proof way to detect KDE, GNOME, etc is to check for X atoms.  The
>>>bigger question is why do you care?  As long as they can display a GUI you
>>>should not be bothered about which one it is.  Especially under the X Window
>>>System it was designed so that random applications DIDN'T know what they were
>>>running under.

>>As the person writing the KDE front-end to the mentioned application, let
>>me answer your question.  The idea is that if the user is running KDE,
>>then they get a KDE front-end by default.  I also hope that should
>>somebody write a GTK/GNOME front-end, if the user was running GNOME they
>>would get a GTK-based front-end by default.  It's good UI design.

Not sure what you mean by 'running KDE' ?? Running kwm? Running kicker? 
KDE libs loaded? KDE installed? I don't think there really is a definite 
meaning for 'running KDE'.

>>>Also remember KDE is not a window manager, it is a desktop environment.  It is
>>>perfectly reasonable to run KDE and use fvwm (or even twm) as the window
>>>manager.  Same applies to GNOME.

>>OK, Andrew meant DE instead of window manager, but it's still a valid
>>question.

>>>Also, what about someone who only runs say
>>>Window Maker and never uses GNOME or KDE?

>>Well, in that case we just choose a default.  The thing is, we want to
>>detect if PyKDE is installed.  If it is, then we can do "import kdecore"
>>without risk of it throwing an exception.  If it isn't, I'd rather not
>>have to try something along the lines of attempting "import kdecore" and
>>then having to catch an exception if it's not found.

> But the only way to see if PyKDE is installed, is to check it, KDE
> doesn't require PyKDE, you can't assume that PyKDE will be present
> simply because someone is running KDE. About the only way I can see you
> toing this, is with a whole lot of try/fail checks, and even then, if
> someone is running something other than KDE/Gnome, you will be back to
> the default. Why not start the default front end first time, then ask
> the user what front end they would prefer, then save that to a dotfile? 

PyKDE normally installs in python/site-packages, so you can check for 
kdecore.py  using os.path.exists() for example, although I don't really 
understand why 'try: import kdecore ...' should be a problem. There are 
more problems with os.path.exists (like knowing for sure what the path 
is) while 'import' failure/success guarantees that Python can't/can find 
kdecore.

In fact to be 100% certain, you'd want be sure _all_ of the PyKDE 
modules you need are accessible - an aborted install could leave a lot 
orphans in site-packages, for example, or someone could have 
deleted/moved a critical file, or hacked the makefiles, or removed 
sip/PyQt and not PyKDE, or upgraded KDE and not PyKDE. 'import' also 
determines that libkdecore.so and similar are also there. It seems that 
what's important  isn't whether it's 'there', but whether it can be run 
- only way to know is to try it. It seems the easiest way is to put all 
of the PyKDE imports in a 'try' block and perhaps set a flag if they all 
succeed.


Jim




More information about the Python-list mailing list