John J. Lee wrote:
> Alternatively, if you feel rather adventurous, try compiling KPDF on
> Windows with the free Qt3 port(s?) or Qt4, if that's arrived yet.
I think you might be slightly too optimistic about getting KPDF to run
natively on Windows. The project you mention does have a page
describing how to run KDE 3.4 on Windows, but I think that may be
taking things further than the original poster intended:
http://kde-cygwin.sourceforge.net/kde3/index.php
I believe someone is working on a Qt 4 renderer for Poppler, a PDF
rendering library based on xpdf, so it could potentially be used in an
application on Windows:
http://poppler.freedesktop.org/
> If you're successful there, you still need to figure out writing KPart
> plugins in Python, which certainly used to be tricky, but maybe that's
> a solved problem by now...
Writing KPart plugins in Python (for embedding into applications) was
never all _that_ tricky; it just required some messing around with
shared libraries. As it turns out, you don't need to do this if you
just want to control KPDF from a client application written in Python.
There are two approaches you can take (for Windows users, this is
where we go off-topic):
1. Use DCOP to control two running instances of KPDF. At the simplest
level, you could use the popen2 module and the "dcop" tool to
control what KPDF displays. This could be integrated into a client
application to varying degrees, with the application getting the
window manager to do things with window placement, but it would
probably end up being a lot of effort for less than the desired
result.
http://developer.kde.org/documentation/tutorials/
2. Use the kparts module from PyKDE to display KPDF KParts in the
client application's GUI. You can still control the KParts via
their DCOP interfaces, and you can call methods on them directly
to, for example, open specific URLs or add user interface elements.
http://www.riverbankcomputing.co.uk/pykde/
Since I discovered how easy it was to embed KPDF like this, it makes
me want to experiment more with using KParts in Python. It's already
trivial to use KHTML from Python, and KParts like these could be used
to create specialised tools for documentation and visualisation.
David
egbert <egbert.bouwman(a)hccnet.nl> writes:
> When I start the following script in a gnome-terminal:
>
> #!/usr/bin/env python
> import os
> print "hello gnome-terminal"
> print os.environ["PYTHONPATH"]
>
> I see the expected results in the same gnome-terminal window.
>
> However starting this same script via a launcher in a panel,
> a new gnome-terminal window is opened for output only,
> and PYTHONPATH is an unknown entity.
> How can I open a terminal over whose environment and
X has been breaking environments this way for decades. You have two
choices:
1) Tell gnome-terminal that it needs to start a login shell, assuming
you can.
2) Move the setting of PYTHONPATH into a different startup file, one
that will be executed by all shells when they start.
Whatever you do, don't ask about .MacOSX/preferences.plist.
<mike
--
Mike Meyer <mwm(a)mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
