Re: [PyQt] How can I capture some mouse events but ignore others?
On Friday 06 March 2009 06:53:01 am Marc Nations wrote: Hi, I'm trying to create a custom table which pops up a menu when the user right clicks. This part works ok. It looks like this: class Table(QtGui.QTableWidget): def __init__(self, parent, gui): QtGui.QTableWidget.__init__(self, parent) self.gui = gui def mouseReleaseEvent(self, event): if event.button() == QtCore.Qt.RightButton: self.rightClickMenu(event) def rightClickMenu(self, event): pos = event.pos self.gui.ui.menuEdit.popup(QtGui.QCursor.pos()) The problem is that the default before of left click is changed, and I can't reset it. Without the mods the left clicks acts where if a multiple selection is made then clicking on another table cell de-selects all the previous items (unless a modifier key is used). With the above method, once multiple selections are made then it basically goes into shift mode and all previous selections are kept. I can't figure out a way to turn that off. Is there a way to cherry pick which mouse events you want and ignore the rest, basically letting them keep their default behavior? Because it looks like once the function is taken over then the default behaviors are lost. Look at QWidget.contextMenuEvent - it catches only right clicks. Overload that. If you want to grab those on the vertical or horizontal headers, I think you'll have to install an event filter on the respective QHeaderViews (QObject.installEventFilter) and grab only QContextMenuEvents for those objects. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] How can I capture some mouse events but ignore others?
On Friday 06 March 2009 09:06:03 am Andreas Pakulat wrote: On 06.03.09 08:40:17, Jim Bublitz wrote: On Friday 06 March 2009 06:53:01 am Marc Nations wrote: Hi, I'm trying to create a custom table which pops up a menu when the user right clicks. This part works ok. It looks like this: class Table(QtGui.QTableWidget): def __init__(self, parent, gui): QtGui.QTableWidget.__init__(self, parent) self.gui = gui def mouseReleaseEvent(self, event): if event.button() == QtCore.Qt.RightButton: self.rightClickMenu(event) def rightClickMenu(self, event): pos = event.pos self.gui.ui.menuEdit.popup(QtGui.QCursor.pos()) The problem is that the default before of left click is changed, and I can't reset it. Without the mods the left clicks acts where if a multiple selection is made then clicking on another table cell de-selects all the previous items (unless a modifier key is used). With the above method, once multiple selections are made then it basically goes into shift mode and all previous selections are kept. I can't figure out a way to turn that off. Is there a way to cherry pick which mouse events you want and ignore the rest, basically letting them keep their default behavior? Because it looks like once the function is taken over then the default behaviors are lost. Look at QWidget.contextMenuEvent - it catches only right clicks. Overload that. If you want to grab those on the vertical or horizontal headers, I think you'll have to install an event filter on the respective QHeaderViews (QObject.installEventFilter) and grab only QContextMenuEvents for those objects. The header views are qwidgets as well, so I don't see why that would be necessary. Because you'd have to subclass them and replace the QTableWidget's original headers. It seems easier to install an event filter, but either method would work. Apart from that, its even possible without overriding any base class, using QWidget.setContextMenuPolicy (set to Qt.CustomContextMenu) and catching the customContextMenuRequested() signal from the same widget. That's probably easier than installing an event filter - wasn't aware of that. Jim Or by using the Qt::ActionsContextMenu and adding a bunch of QActions to the table. Then you don't even need to take care of creating a menu. Andreas ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pdf print
On Thursday 26 February 2009 13:41:41 pm Nahuel Defossé wrote: Hi I've created pdf output in a StringIO file which I'd like to print in my PyQt4 app. Should I save it and send it to the system default reader? or could I automate this task? Is it possible to pirnt the file directly from PyQt? Thanks Nahuel I use pdfs for checks, invoices, etc. ReportLab lets you do very precise layout easily. I just save them as a temporary file and then use os.system and an lpr command to send them to the printer (under Linux): Then cups worries about finding the printer, checking its status, managing the queue, translating to Postscript, etc. Not sure how you'd do it with Windows or if you can send pdfs directly to the printer. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: LGPL license.
On Tuesday 10 February 2009 13:30:24 pm Robert Kern wrote: pyKDE is ??? LGPL??? No, PyKDE is GPL. http://sourceforge.net/projects/pykde PyKDE4 is LGPL (per KDE request, more or less). The docs are (were?) Creative Commons. I'm not sure what PyKDE3 is - it's basically whatever I want it to be. But it still depends on PyQt, and since Phil has been the author and sole maintainer for something close to 10 years, PyQt ought to be whatever he wants it to be. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] LGPL license.
On Tuesday 10 February 2009 14:41:02 pm Knapp wrote: Oh, btw what implications it has for your application/development to use Qt or PyQt licensed under GPL or LGPL or commercial is something you should discuss with a lawyer. Andreas Yes, all is clear now, thanks. This bit about the lawyer always strikes me as funny. I am looking at releasing a product that will be sold in the USA, Canada, England, Australia and many other English speaking places. It will also be sold in other countries as the translators get things done, perhaps Germany first. The product is expected to cost 20 to 50 USD and sell a few thousand units per county, if it goes well. So how much does this lawyer that knows all about these licenses and there effects in all those counties cost? Where do you find him? Considering you're going to generate huge profits from this product, it wouldn't hurt to ask the author of a fundamental component of the product how much a commercial license would cost and pay for it, and then you wouldn't have to worry about GPL, LGPL or any of that stuff. I've never minded people using my software for free - even commercially. I just hate it when they whine about software being free, but not on terms where they can profit enormously from other people's work. It's the whining, not the profiting, that I object to. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] LGPL license.
On Tuesday 10 February 2009 19:44:12 pm Arthur Pemberton wrote: And I empahisze with Jim and having to deal with whinners. They get into every open source project and drain the lead developers of their drive -- it's pretty unfortunate. I hope Jim does what is best for him, as much as I would like an LGPL PyQt at some point soon. Just to be clear - I don't have anything to do with PyQt. That's all Phil, and has been from the start. I did maintain PyKDE (also initiated by Phil) for 6 or 7 years. Simon Edwards has taken it over in the last 6 months or so, and seems to be doing a terrific job, especially since he took it over when it was half done. Having had fantastic support from Phil from before I even started PyKDE, I appreciate how much effort he puts into PyQt, and how much he has enhanced it over the years (and broken PyKDE with every enhancement :) ). I'm going to be starting a PyQt4 project soon, and I really appreciate having it available. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KHTMLPart mouse events
On Friday 09 January 2009 08:50:07 am Christoph Burgmer wrote: Jim, Simon, I hope you can help me. I am trying to track a user's MidButton mouse click to track paste actions. It seems that khtmlMousePressEvent (khtml::MousePressEvent* event) is the right place to do that, but the sip-file does not have those mouse event methods, they are commented out. Can that be changed in a later version? Is there a reason for them not being activated? The KHTMLPart itself does the MidButton action in these methods[1]. I suspect that khtml::MousePressEvent is not a class that's exposed in the public KDE API - meaning it's declared in some file that PyKDE doesn't wrap. So if you got one, you couldn't do anything with it anyway, since it's not a wrapped class. However, there are mouse events (QMouseEvent) available in KHTMLView, and you can get the KHTMLView object from the part by calling it's view() method. Don't know if those will do what you want, but it seems like they should. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt4.Qtcore defines 'hex'
On Wednesday 07 January 2009 05:27:06 am Sundance wrote: Adeodato Simó wrote: If you see in the middle of a program hex_(foo), you may wonder where that came from, whereas qhex(foo) is going to be rather obvious. Greetings all, Might I humbly second this motion? I do understand the usual reservations about star-imports (being the kind of guy that often gets to debug other people's work...), but I also do appreciate the relative ease of getting away with it in PyQt's case, thanks to the prevalence of the Q prefix in its class names and its relative absence of module-level functions. With this in mind, using the same prefix for the three problematic functions makes good sense to me. Are there reservations about this approach that I may not be aware of? One problem I'd see is that 'qhex' doesn't sort alphabetically the same as 'hex' or 'hex_' does. Also, other bindings - like PyKDE - have the same problem. In the case of PyKDE, it's in a lot more than three places. That makes it a lot harder for people to find it in the docs, especially if they're coming from or reconciling with Qt or KDE docs and method names. The 'q*' convention doesn't make a lot of sense for other bindings packages, and the underscore seems less likely to clash with other people's naming schemes, although in the case of PyQt a clash seems to have a fairly low probability either way. As to the ugliness factor, I somewhat agree, but then we're talking about a language that uses things like __init__ or __main__ all over the place. As to '*' imports - having done a lot of C/C++ where you have to declare every variable, declaring objects in an import statement isn't that difficult. And IIRC, PyKDE4 inherits name clashes between modules from KDE itself in a couple of places. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QCheckBox problem
On Sunday 04 January 2009 17:30:41 pm Doug Hackworth wrote: Greetings. This should be an easy one for someone to answer. Simple situation: I have a QCheckBox on a main window along with other widgets, but mysteriously it won't do anything. Since all my other widgets (buttons, mainly) do what they're supposed to, I suspect I am using the QCheckBox incorrectly. It's the first time I've tried using one. I am attempting to connect the checkbox's toggled() signal to a slot with this line: code QtCore.QObject.connect(self.ui.checkMyCheckbox, QtCore.SIGNAL(toggled()), self.MyCheckboxSlotFunction) /code Here is the slot I have defined for it: code def CheckMultiMask(self): sys.stdout.write(checkbox toggleded\n) if (self.ui.checkMyCheckbox.isChecked()): sys.stdout.write(it's checked\n) /code When the window loads, however, I can click on the QCheckBox all I want, to no avail. Also, the application object doesn't complain when it loads, and I know it's getting to the connect() invocation quoted above... I just don't know why the slot function doesn't seem to ever be invoked. And again, my other widgets with signals/slots connected by me (in a manner like that above) are behaving as expected. Any thoughts from the experts? I'll be happy to provide further information on context if it's useful. BTW, I'm using Ubuntu 7.10 and the following versions of PyQt / Qt: $ pyuic4 --version Python User Interface Compiler 4.3 for Qt version 4.3.2 (The MainWindow was constructed with Qt Designer by way of pyuic4.) If the code you've provided is what you actually have, you haven't connected the signal to the slot you show - instead of self.MyCheckboxSlotFunction, you should be connecting to self.CheckMultiMask. If that isn't the problem, it'd help someone to figure it out if you could provide a complete small executable program that exhibits the problem behavior. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KIntNumInput question
On Sunday 21 December 2008 07:40:25 am Neal Becker wrote: num_in = KIntNumInput (self, 0, 0, 16) gives: TypeError: too many arguments to KIntNumInput(), 1 at most expected But according to http://api.kde.org/pykde-4.1-api/kdeui/KIntNumInput.html#obj175289196 There are constructors taking 1,2, and 3 args. What am I missing? Is there some other doc I should be looking at? The docs you linked are a little confusing. If you were calling __init__ directly, you'd pass 'self'. But since you're calling the constructor instead, the 'self' argument isn't used. Since KIntNumInput is ultimately a subclass of QWidget, sip appears to be choosing the single argument constructor - KIntNumInput (QWidget), where the QWidget is 'self', and for that constructor only a single argument is passed. If you drop the 'self' argument, it should work. Seems like the docs should show you how to put together a constructor properly. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: KIntNumInput question
On Sunday 21 December 2008 14:22:03 pm Neal Becker wrote: Jim Bublitz wrote: On Sunday 21 December 2008 07:40:25 am Neal Becker wrote: num_in = KIntNumInput (self, 0, 0, 16) gives: TypeError: too many arguments to KIntNumInput(), 1 at most expected But according to http://api.kde.org/pykde-4.1-api/kdeui/KIntNumInput.html#obj175289 196 There are constructors taking 1,2, and 3 args. What am I missing? Is there some other doc I should be looking at? The docs you linked are a little confusing. If you were calling __init__ directly, you'd pass 'self'. But since you're calling the constructor instead, the 'self' argument isn't used. Since KIntNumInput is ultimately a subclass of QWidget, sip appears to be choosing the single argument constructor - KIntNumInput (QWidget), where the QWidget is 'self', and for that constructor only a single argument is passed. If you drop the 'self' argument, it should work. Seems like the docs should show you how to put together a constructor properly. Jim num_in = KIntNumInput (0, 0, 16) TypeError: argument 2 of KIntNumInput() has an invalid type Can't help you there - I don't have PyKDE4 installed. A short example program would help someone else test it. The only thing I'd suggest is to try passing 'None' for the 2nd (QWidget) argument. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt4-extrawidgets project
On Tuesday 11 November 2008 09:04, piotr maliński wrote: I've started a project at code.google.com that contains all PyQt4 widgets made by me with the help of SIP. http://code.google.com/p/pyqt4-extrawidgets/ Currently there are two widgets: QTermWidget and qt-macnavbar (screenshot: http://www.fotosik.pl/pokaz_obrazek/pelny/cb4b8531394f7906.html). Both do work, but some small issues still remain that I have to fix. QTermWidget doesn't want to resize (I'll have to probably bind all core header files for it), and Qf-MacNavBar has few methods/properties commented out (but it works). SIP doesn't like such code: ## QString title (void) const; bool isExpanded (void) const; ## as it says: sip: QfNavBarGroup::title() unsupported function argument type - provide %Method code and a valid C++ signature. I'm not a C/C++/SIP guru so I can't fix this. Any solutions welcomed. Remove the 'void' in each function declaration (in the sip file - in the h file it makes no difference).. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] design flaw in python khtml DOM bindings
On Tuesday 14 October 2008 14:21, Luke Kenneth Casson Leighton wrote: folks, hi, thanks to some kind people on the kde-dev mailing list i'm posting here to describe an important design issue which makes the python khtml.DOM bindings completely unusable - for serious projects - unless it's fixed. the issue is that the wrapper objects aren't unique [don't return the same python object for a given DOM c++ object], due to the underlying c++ objects being typecast down to Node* (or Element*), and the use of the khtml.DOM.* casting functions being inadequate for the job. the issue is described in detail here: http://lists.kde.org/?l=kde-develm=122398222122025w=2 the bugreport is here: https://bugs.kde.org/show_bug.cgi?id=172740 an example of the code which gets it _right_ - in webkit - is here: http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom note the quite extensive html element wrapper factory, the extensive GDOMBindings.cpp which basically cover EVERY single object and i mean ALL of them, with a wrapper that ALWAYS goes via the Hashmap before returning the object. in this way, it is absolutely absolutely cast-iron-guaranteed that, even when you call KHTMLPart.document.getElementById(body_id) you WILL get a khtml.DOM.HTMLBodyElement back - NOT a khtml.DOM.Node. It's a bug in twine - the PyKDE code generator. It should be generating code to cast factory-generated types to their actual type, and does for a variety of base classes (eg, QObject). DOM::Node is specified in the project file to have a %ConvertToSubClassCode block generated for it, but it appears twine is ignoring those for any base class declared in a namespace (works for subclasses in namespaces though). It'll work if dynamic_cast works for the class and hierarchy (not compiled with -fNO_RTTI or whatever the switch is that turns off RTTI) Richard Dale's fix linked about should also work in this case if rolled into a proper %ConvertToSubClassCode block. However, in some cases like this, the KDE base class/derived classes don't have type info methods attached - twine's code should work generally if RTTI is enabled. But it wouldn't be maintained automatically, and you'd also have to add #includes for each subclass' header file, which twine should do automatically as well. i cannot express enough how much _not_ fixing this makes khtml completely unusable. There were DOM applications written for PyKDE3, which also didn't do any promotion of factory-generated DOM::Node objects, and nobody indicated it was a problem there. Which is why it was never checked. Either way, it shouldn't be hard to fix. And then somebody (like people who need the feature and know how it should work) should write/contribute some test code to make sure it stays fixed. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] [PyKDE] KTextEditor interface classes
On Friday 29 August 2008 15:02, Paul Giannaros wrote:
KTextEditor works with an interface class -- implementors of the
interface subclass
KTextEditor::View and KTextEditor::Document, with the subclasses also
inheriting from any interfaces that they choose to support. This is a
problem -- I can't see
a way to cast to the required type.
Even though I can check at run-time whether my view implements an interface
with something like:
document = Kate.application().documentManager().documents()[0]
view = document.activeView()
view.inherits('KTextEditor::ConfigInterface')
True
I cannot use anything to cast to the appropriate type to get at the
methods provided
by the interface.
Is there a solution to this problem?
Are the parent classes also wrapped in your module?
If they are, you can use %ConvertToSubClassCode (CTSCC) - see it's use in
PyKDE or PyQt for examples and the sip docs (not all PyKDE classes have
inherits() available, so they use dynamic_cast; PyQt code uses inherits()).
For example, if a call creates a QWidget but returns (in C++) a QObject,
CTSCC will cast the returned object to QWidget in the Python program.
Otherwise there are ways to cast within Python using sip functions (see the
sip docs), but they probably aren't what you want.
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] [PyKDE] KTextEditor interface classes
On Friday 29 August 2008 16:19, Paul Giannaros wrote:
On Fri, Aug 29, 2008 at 11:47 PM, Jim Bublitz [EMAIL PROTECTED]
wrote:
On Friday 29 August 2008 15:02, Paul Giannaros wrote:
KTextEditor works with an interface class -- implementors of the
interface subclass
KTextEditor::View and KTextEditor::Document, with the subclasses also
inheriting from any interfaces that they choose to support. This is a
problem -- I can't see
a way to cast to the required type.
Even though I can check at run-time whether my view implements an
interface
with something like:
document = Kate.application().documentManager().documents()[0]
view = document.activeView()
view.inherits('KTextEditor::ConfigInterface')
True
I cannot use anything to cast to the appropriate type to get at the
methods provided
by the interface.
Is there a solution to this problem?
Are the parent classes also wrapped in your module?
Firstly, it's not my module: ktexteditor is part of PyKDE4! Most of the
interface classes are wrapped, yes (it looks like some may be
missing, though; I can see KTextEditor::AnnotationInterface exists
but no sip binding for it exists according to websvn).
I dropped it from PyKDE4 to make the package smaller - Simon apparently added
it back.
You need to communicate with Simon Edwards and a) get the classes you need
into the bindings and b) get the CTSCC blocks generated (it's done
automatically via the project file).
If they are, you can use %ConvertToSubClassCode (CTSCC) - see it's use in
PyKDE or PyQt for examples and the sip docs (not all PyKDE classes have
inherits() available, so they use dynamic_cast; PyQt code uses
inherits()).
For example, if a call creates a QWidget but returns (in C++) a QObject,
CTSCC will cast the returned object to QWidget in the Python program.
I'm not sure how this will help. I don't want the KTextEditor::View object
to always be returned to me as a KTextEditor::ConfigInterface. I need some
way to get at a ConfigInterface (and a CursorInterface, SearchInterface,
etc) from a View instance. I'd be happy if View objects had a method like
configInterface() to return the interface where available.
Right - that's what %ConvertToSubClassCode will do for you. In PyKDE the code
in the sip file (C++ code) tries to dynamic_cast to a subclass type and will
return the most-derived type it can find. I'm assuming CursorInterface,
SearchInterface, etc are subclasses of ConfigInterface. It seems to me that's
what you want, but maybe I'm misunderstanding.
If that's not what you want, then it seems you'll have to write C++ code and
add it to the bindings, which is not that hard to do.
Jim
Otherwise there are ways to cast within Python using sip functions (see
the sip docs), but they probably aren't what you want.
Unfortunately not. sip.cast only lets you cast to instances of
superclasses.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Auto-generate sip specification file?
On Thursday 14 August 2008 17:02, Mark A. Schmucker wrote: Hi, I used SIP today to generate a wrapper for one class in my library. My library has about 50 classes, and I want to wrap most of them. Now that I have things set up, it won't be too hard to copy each header file and manually edit them to create SIP specification files. But as the classes change, I'll need to maintain the SIP files too. Are there any tools that would help automate this process? Phil has a gcc-xml based tool he uses to generate PyQt, but I'm not sure if he wants to make it generally available (there are lots of good reasons not to). Simon Edwards is using a tool for PyKDE4 called twine whose lexer./parser are based on PLY and which will generate a versioned set of sip files (one that, at least in theory, will build for any version of your lib). It also handles multiple modules, and will produce a set of HTML class docs from doxygen markup. It's GPL'd. There isn't much in the way of docs. It requires a project file (PyKDE4's project file can be used as an example) and has a few quirks. It's entirely written in Python and takes under 2 minutes to generate all of PyKDE4's sip files and HTML docs from KDE h files. It probably has some PyKDE specific stuff that needs to be worked out to make it a general purpose tool (for example it automatically builds a PyKDE4 directory structure, but the code that does that is a plugin that's easily replaced). If Simon doesn't chime in with a location where it's available, email him - simon AT simonzone.com :) Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 documentation?
On Wednesday 30 July 2008 02:41, Benno Dielmann wrote: Hi, http://techbase.kde.org/Development/Languages/Python/Using_PyKDE_4 says there are several tutorials on programming in PyKDE4. Where can they be found? They were in the PyKDE4 tarball in the tutorials/ directory. I think the only one I completed was Getting Started, which is pretty basic. I think Simon wrote up some docs for pykdeuic too. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE application crashes on exit
On Wednesday 30 July 2008 12:56, Benno Dielmann wrote:
Hi,
This PyKDE4 application always crashes on exit:
-
import sys
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyKDE4.kdecore import ki18n, KAboutData, KCmdLineArgs
from PyKDE4.kdeui import KApplication
class Benup(QWidget):
def __init__(self, parent=None):
super(Benup, self).__init__(parent)
self.splash = QLabel('testing...')
layout = QVBoxLayout()
layout.addWidget(self.splash)
self.setLayout(layout)
if __name__ == '__main__':
appName = benup
catalog =
programName = ki18n(Benup)
version = 0.1
aboutData = KAboutData(appName, catalog, programName, version)
KCmdLineArgs.init(sys.argv, aboutData)
app = KApplication()
b = Benup()
b.show()
app.exec_()
-
Any ideas why? It doesn't crash if I make self.splash local, i.e. removing
the self.. What am I doing wrong?
I'm not completely certain of this, but some of the shutdown/cleanup code for
KDE apps has historically been in KMainWindow (or descendants like
KXMLGuiWindow, KParts.MainWindow). So I'd try making Benup a subclass of one
of those.
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] sip doesn't recognize structs with parent structs/classes
On Wednesday 16 July 2008 16:12, Erick Tryzelaar wrote:
I've got a simple sip file that has:
struct Foo {
%TypeHeaderCode
#include foo.h
%End
virtual Foo();
};
struct Bar: Foo {
%TypeHeaderCode
#include foo.h
%End
virtual Bar();
};
That should be valid code though, right?
It's valid C++, sip may or may not accept it (sip only covers a meaningful
subset of C++), and it's identical to the following code which sip will accept:
class Foo {
%TypeHeaderCode
#include foo.h
%End
public:
virtual Foo();
};
class Bar: Foo {
%TypeHeaderCode
#include foo.h
%End
public:
virtual Bar();
};
Jim___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
On Sunday 15 June 2008 06:36, Adeodato Simó wrote: * Simon Edwards [Sun, 15 Jun 2008 15:07:28 +0200]: sip - 4.7.6 Qt - 4.4.0 PyQt - 4.3.3 -- note this KDE - 4.0.80 PyKDE4 - 4.0.2 (from Riverbank) If I upgrade PyQt to 4.4.2, things stop working. Also note how running PyQt 4.3 against Qt 4.4 works, and PyKDE4 against KDE 4.0.80 too. So, Jim, sounds like a change in PyQt, yes. No idea if this could be related to the fix Simon mentions or not. Did you recompile PyKDE4 against the new version of PyQt4? When recompiling PyKDE4, did it see that PyQt 4.4 was being used? No, I didn't, and I really hope the answer is not You need to. Unfortunately, you do need to recompile PyKDE any time you change sip or PyQt versions. I wouldn't guarantee that will fix the problem, but it's a first step. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
On Friday 13 June 2008 08:19, Adeodato Simó wrote: * Jim Bublitz [Fri, 13 Jun 2008 07:50:31 -0700]: PyKDE3 or PyKDE4? Er, PyKDE4 (since I said I was using PyQt 4.4...) But you're trying to use KDE3 syntax. There is no KAboutData ctor that takes only a char string (or QString). Look at the PyKDE4 docs or: http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKAboutData.html There are examples in PyKDE4 that demonstrate KAboutData (in fact every example uses KAboutData) Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
On Saturday 14 June 2008 11:52, Adeodato Simó wrote: * Jim Bublitz [Sat, 14 Jun 2008 10:37:07 -0700]: Hello, On Friday 13 June 2008 08:19, Adeodato Simó wrote: * Jim Bublitz [Fri, 13 Jun 2008 07:50:31 -0700]: PyKDE3 or PyKDE4? Er, PyKDE4 (since I said I was using PyQt 4.4...) But you're trying to use KDE3 syntax. There is no KAboutData ctor that takes only a char string (or QString). Look at the PyKDE4 docs or: http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKAboutData.h tml There are examples in PyKDE4 that demonstrate KAboutData (in fact every example uses KAboutData) I know what the signature of KABoutData looks like in PyKDE4. My point was that passing a string for the first argument raises invalid type. You get the same error if you specify all the arguments, or only one, so I saved myself from typing them all. (I can see how my example could confuse you, though, so in the future I'll try not to do that again.) It works here with Qt 4.3/PyQt 4.3.3/sip 4.7.4/KDE 4.0.2/PyKDE 4.0.2. I doubt there's been a change in KDE (you don't indicate a version), so it's likely there's some change in sip or PyQt that's causing the problem. I'll have to upgrade to troubleshoot it, and that may take me a while to get to. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KAboutData() broken when using PyQt 4.4
On Friday 13 June 2008 01:23, Adeodato Simó wrote:
Hello,
I upgraded to PyQt 4.4.2 this morning, and now KAboutData no longer
works for me:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: argument 1 of KAboutData() has an invalid type
Instead of the expected:
kdecore.KAboutData('foo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: insufficient number of arguments to KAboutData()
This has broken my application, any ideas?
PyKDE3 or PyKDE4?
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE: problems sending singals to KPART
On Wednesday 04 June 2008 23:42, Thomas Winkler wrote: Hello, Yes - short of writing some C++ DCOP would be the solution, if KPDF exposes a sufficient interface via DCOP, which apparently it does. [...] There is an example (example_dcopext.py) in PyKDE/examples. I had a look at the example. My feeling however is that it is not an option for me since, contrary to the example, I want to embed the kpart in my application instead a launching a separate process. For DCOP control as shown in the example I need the $PROCNAME-$PID id string which I obviously do not have. While writing the above the idea came to my mind that I could simply use the the name and pid of my own app which embeds the kpdf part and send dcop messages to my own app to control the kpdf part. So far so good. My app is planned to embed more than just one kpdf kpart but when inspecting my app with kdcop I only could see one single kpdf component (eben though my app has two of them). Using kdcop I can send messaes to the kpdf part. They are executed for the kpdf kpart that was last instantiated. I could not find a way to control the other kpdf kpart as it does not show up in kdcop. What is the reason for that? You could fork each of the KPDF processes, and they'd have unique PIDs then. Another possibility is QXEmbed (should be an example for that in PyKDE too), however that can be somewhat unreliable in my experience with it. You could also use KHTMLPart for the GUI and have that launch KPDF instances, although I don't know if that buys you any more control in your application. Coming back to the idea of writing some own c++ code: What exactly would I have to write? You would need a wrapper which 1) loads (or links to) the .so lib KPDF is based on (and since it's a KPart, it has a .so lib) and 2) makes the KPDF methods you want to use available in Python. If you only want a method or two, you could look at the Python/C API to accomplish both of those. Most good books on Python usually include something about writing C modules to interface to Python. Otherwise, you can write a C++ wrapper that exposes the classes/methods you need and do bindings for it using sip. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
On Wednesday 21 May 2008 07:04, Darren Dale wrote: On Tuesday 20 May 2008 03:29:14 pm Jim Bublitz wrote: On Tuesday 20 May 2008 10:47, Darren Dale wrote: At that point, I get another can't use default assignment operator error: I'm not sure what's causing that error, which seems to be the basic problem (other than having an updated configure.py). I haven't downloaded the latest KDE yet, but will have to do that and see if I can reproduce the problem. If I comment out //%Include kencodingdetector.sip, configure.py fails: ... Generating the C++ source for the kdeui module... sip: KEncodingDetector::AutoDetectScript is undefined Error: Unable to create the C++ code. --- Is there something else I should try at this point? KCodecAction (sip/kdeui/kcodecaction.sip) depends on KEncodingDetector. You can either comment out the KEncodingDetector references in kcodecaction.sip or comment out that sip file in sip/kdeui/kdeuimod.sip.in. I did the latter. Then I needed to comment out additional lines in sip/kdecore/kdecoremod.sip.in: //%Include kcharsets.sip //%Include kcmdlineargs.sip //%Include klockfile.sip At that point, I got an error that I have not been able to work around: g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -march=k8 -mtune=k8 -pipe -fomit-frame-pointer -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde404 -I/usr/kde/4.0/include -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork -I/usr/kde/4.0/include/sonnet -I/usr/include/python2.5 -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -I/usr/X11R6/include -o sipkdecoreKTimeZoneSource.o sipkdecoreKTimeZoneSource.cpp /usr/kde/4.0/include/ktimezone.h: In member function 'KTimeZoneSource KTimeZoneSource::operator=(const KTimeZoneSource)': /usr/kde/4.0/include/ktimezone.h:1224: error: non-static const member 'KTimeZoneSourcePrivate* const KTimeZoneSource::d', can't use default assignment operator sipkdecoreKTimeZoneSource.cpp: In function 'void assign_KTimeZoneSource(void*, const void*)': sipkdecoreKTimeZoneSource.cpp:167: note: synthesized method 'KTimeZoneSource KTimeZoneSource::operator=(const KTimeZoneSource)' first required here make[1]: *** [sipkdecoreKTimeZoneSource.o] Error 1 make[1]: Leaving directory `/home/share/packages/PyKDE4-4.0.2-1/kdecore' make: *** [all] Error 2 configure.py fails if I comment out //%Include ktimezone.sip. I tried to find a work around similar to the one you suggested for KEncodingDetector, but was not successful. I also tried to understand what is actually causing these can't use default assignment operator errors, but unfortunately I don't have enough experience yet with C/C++ to follow the discussions I found on google. Sorry. It's either a change in gcc or a change in the KDE source (note that the errors are coming from the KDE h file, not from PyKDE). You're getting into files now that are useful (most of the previous stuff wasn't esp needed for most people), and just playing whack-a-mole. It's likely to continue until there isn't anything of PyKDE left to compile. I'll have to upgrade/download and see if I can set up the same environment and reproduce the errors you're getting (and then fix them, of course). It's going to take a while to accomplish all of that, but I will get back to you. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
On Tuesday 20 May 2008 10:47, Darren Dale wrote: At that point, I get another can't use default assignment operator error: I'm not sure what's causing that error, which seems to be the basic problem (other than having an updated configure.py). I haven't downloaded the latest KDE yet, but will have to do that and see if I can reproduce the problem. If I comment out //%Include kencodingdetector.sip, configure.py fails: ... Generating the C++ source for the kdeui module... sip: KEncodingDetector::AutoDetectScript is undefined Error: Unable to create the C++ code. --- Is there something else I should try at this point? KCodecAction (sip/kdeui/kcodecaction.sip) depends on KEncodingDetector. You can either comment out the KEncodingDetector references in kcodecaction.sip or comment out that sip file in sip/kdeui/kdeuimod.sip.in. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
I think I must have a different version of configure.py than you are
expecting. I'm using the one that comes with pykde-4.0.2-1 at the
riverbankcomputing website. It doesnt have a variable called
opt_qt_inc_dir, nor a statement like if incdir.startswith ('Q'). Here is
part of configure.py, starting at line 587:
That seems to be the problem. Try the attached configure.py. It should be the
one that's in PyKDE4 tarball, but I've checked and this should have the logic
for setting up the include paths correctly. Not sure what happened here.
I'll be away from my computer until Sat night/Sun morning.
Jim
configure.py
Description: application/python
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
On Wednesday 14 May 2008 10:27, Darren Dale wrote: I am working on compiling pykde4-4.0.2-1. I have installed qt-4.4_rc1 (I know the final version is out, gentoo hasnt included it yet in their package manager) sip-4.7.5, qscintilla-2.2, and PyQt4-4.4. When I run configure.py, I get an error: Generating the C++ source for the kdecore module... sip: sip/kdecore/typedefs.sip:263: %MappedType template for this type has already been defined Error: Unable to create the C++ code. Has anyone been able to build PyKDE-4.0.2-1 with the most recent sip/QScintilla/Qt/PyQt4 environment? Is there a PyKDE-4.0.3 available? (kubuntu lists it in their package manager, but I havent been able to find the sources.) I have my development machine on a different project at the moment, so I can't check this explicitly, but the likely problem is that PyQt4 has added a definition for a template type that wasn't provided previously. The fix would be to comment out (/* .. */, not Python comment) the entire %MappedType block begining at the line indicated (including any preceding template annotation) in sip/kdecore/typedefs.sip. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
On Wednesday 14 May 2008 12:09, Darren Dale wrote: On Wednesday 14 May 2008 01:58:37 pm Jim Bublitz wrote: On Wednesday 14 May 2008 10:27, Darren Dale wrote: I am working on compiling pykde4-4.0.2-1. I have installed qt-4.4_rc1 (I know the final version is out, gentoo hasnt included it yet in their package manager) sip-4.7.5, qscintilla-2.2, and PyQt4-4.4. When I run configure.py, I get an error: Generating the C++ source for the kdecore module... sip: sip/kdecore/typedefs.sip:263: %MappedType template for this type has already been defined Error: Unable to create the C++ code. Has anyone been able to build PyKDE-4.0.2-1 with the most recent sip/QScintilla/Qt/PyQt4 environment? Is there a PyKDE-4.0.3 available? (kubuntu lists it in their package manager, but I havent been able to find the sources.) I have my development machine on a different project at the moment, so I can't check this explicitly, but the likely problem is that PyQt4 has added a definition for a template type that wasn't provided previously. The fix would be to comment out (/* .. */, not Python comment) the entire %MappedType block begining at the line indicated (including any preceding template annotation) in sip/kdecore/typedefs.sip. Thank you Jim, it looks like commenting that part out worked. I also had to do: cp extra/kde402 extra/kde403 and for good measure: cp extra/kde402 extra/kde404 in order to avoid some errors like: In file included from sipkdecoreQPair.cpp:7: sip/kdecore/ksycocafactory.sip:26:28: error: ksycocafactory.h: No such file or directory However, now when I run make I get an error that I am unable to diagnose on my own again: g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -march=k8 -mtune=k8 -pipe -fomit-frame-pointer -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde403 -I/usr/kde/4.0/include -I/usr/kde/4.0/include/QtCore -I/usr/kde/4.0/include/QtGui -I/usr/kde/4.0/include/QtNetwork -I/usr/kde/4.0/include/sonnet -I/usr/include/python2.5 -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/X11R6/include -o sipkdecoreKCharMacroExpander.o sipkdecoreKCharMacroExpander.cpp /usr/kde/4.0/include/kmacroexpander.h: In member function 'KMacroExpanderBase KMacroExpanderBase::operator=(const KMacroExpanderBase)': /usr/kde/4.0/include/kmacroexpander.h:39: error: non-static const member 'KMacroExpanderBasePrivate* const KMacroExpanderBase::d', can't use default assignment operator /usr/kde/4.0/include/kmacroexpander.h: In member function 'KCharMacroExpander KCharMacroExpander::operator=(const KCharMacroExpander)': /usr/kde/4.0/include/kmacroexpander.h:224: note: synthesized method 'KMacroExpanderBase KMacroExpanderBase::operator=(const KMacroExpanderBase)' first required here sipkdecoreKCharMacroExpander.cpp: In function 'void assign_KCharMacroExpander(void*, const void*)': sipkdecoreKCharMacroExpander.cpp:279: note: synthesized method 'KCharMacroExpander KCharMacroExpander::operator=(const KCharMacroExpander)' first required here make[1]: *** [sipkdecoreKCharMacroExpander.o] Error 1 make[1]: Leaving directory `/home/share/packages/PyKDE4-4.0.2-1/kdecore' make: *** [all] Error 2 I'm running 64-bit gentoo linux, gcc-4.2.3. Do you have any advice? That's an odd one - check sip/kdecore/kmacroexpander.sip for any instances of operator = and remove them - shouldn't be there, but they may get picked up in the KDE svn version by mistake (automatically generated code). If you find those, remove them. Otherwise, go into sip/kdecore/kdecoremod.sip.in and comment out (//) the line %Include kmacroexpander.sip It's not a particularly useful set of classes and nothing else depends on it in PyKDE as far as I know. I actually looked at the code for this one - forgot I could just mount the PyKDE partition and view it. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] configuring pykde4, error
On Wednesday 14 May 2008 13:54, Darren Dale wrote:
On Wednesday 14 May 2008 04:14:43 pm Jim Bublitz wrote:
On Wednesday 14 May 2008 12:09, Darren Dale wrote:
On Wednesday 14 May 2008 01:58:37 pm Jim Bublitz wrote:
On Wednesday 14 May 2008 10:27, Darren Dale wrote:
g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -march=k8 -mtune=k8
-pipe -fomit-frame-pointer -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde403 -I/usr/kde/4.0/include
-I/usr/kde/4.0/include/QtCore -I/usr/kde/4.0/include/QtGui
-I/usr/kde/4.0/include/QtNetwork -I/usr/kde/4.0/include/sonnet
-I/usr/include/python2.5 -I/usr/share/qt4/mkspecs/default
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4
-I/usr/X11R6/include -o sipkdecoreKSocketFactory.o
sipkdecoreKSocketFactory.cpp
/usr/share/sip/QtNetwork/qtcpsocket.sip:42:24: error: qtcpsocket.h: No such
file or directory
/usr/share/sip/QtNetwork/qtcpserver.sip:42:24: error: qtcpserver.h: No such
file or directory
/usr/share/sip/QtNetwork/qhostaddress.sip:46:26: error: qhostaddress.h: No
such file or directory
/usr/share/sip/QtNetwork/qudpsocket.sip:46:24: error: qudpsocket.h: No such
file or directory
/usr/share/sip/QtNetwork/qnetworkproxy.sip:42:27: error: qnetworkproxy.h:
No such file or directory
make[1]: *** [sipkdecoreKSocketFactory.o] Error 1
make[1]: Leaving directory `/home/share/packages/PyKDE4-4.0.2-1/kdecore'
make: *** [all] Error 2
I searched for qtcpsocket.h and came up with:
/usr/include/qt4/Qt/qtcpsocket.h
/usr/include/qt4/QtNetwork/qtcpsocket.h
gentoo is splitting qt-4.4 into seperately installable modules. I don't
know if that is surprising to anyone or not, is this a nonstandard location
for qt headers? I didn't see an option in configure.py to direct make to
the qt headers. Have I overlooked anything?
Around line 100 in configure.py there's a Python dict where the keys are the
module name and the values are a list of include paths - QtNetwork should be
in the list for kdecore.
What you're showing above for an include path is:
-I/usr/kde/4.0/include/QtNetwork
Does that path really exist? I'm not sure how configure.py is coming up with
that - notice that you have what look like correct qt4 paths farther down,
but none for QtNetwork.
Just from a quick look at my Qt4.3 install, it looks like the Qt/ directory
just duplicates the files from QtNetwork/, so I don't think that Qt/ needs to
be included.
What would help is if a) you could post a copy of the info at the beginning of
configure.py's run - where it thinks everything is. It should be finding the
Qt directories from your PyQt4 installation (there should be a pyqtconfig.py
file in site-packages/ or site-packages/PyQt4 that has the paths from the
PyQt4 install) - it doesn't actually look for those; and b) around line 607
in configure.py, there should be a statement:
if incdir.startswith ('Q'):
If you could add:
print incdir, opt_qt_inc_dir
*before* that 'if' stmt, it should indicate if QtNetwork is being added as an
include path. A print statement after the 'if' (in it's block) would indicate
whether the include path is being added to the Makefile.
It seems like the directory layout isn't something configure.py is expecting.
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Screenshots in linux
On Monday 05 May 2008 13:22, Jake Richards wrote: Hello: Does anyone have any idea how I might select a region of my desktop and then take a screen grab of it? The screenshot example shows me how to grab the snapshot, but the hard part (at least for me) is changing my mouse cursor to some crosshairs and drawing a region on the desktop that I'd like to grab. Can I make a transparent Always On Top window and get mouse clicks from it? Anyone done something like this before and have any hints? Thanks! In KDE you can use KSnapshot. There's also xgrab (segfaults on my system) and Gnome probably has something. For a console you can just cut and paste. KSnapshot includes a settable time delay and the ability to only grab the window containing the mouse or the entire screen or a region. You can always crop or scale a screenshot with something like xv or gimp. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] kdecore.KProcess.Communication enum not OR-able
On Saturday 12 April 2008 06:04, Wilbert Berendsen wrote:
Hi,
The KDE docs say that you can OR the values of the
kdecore.KProcess.Communication enum when start()ing a KProcess.[1]
However that seems not to be possible:
from kdecore import *
p=KProcess()
p.setExecutable('cat')
True
p.start(KProcess.NotifyOnExit, KProcess.Stdin | KProcess.Stdout)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: argument 2 of KProcess.start() has an invalid type
type(KProcess.Stdin | KProcess.Stdout)
type 'int'
type(KProcess.Stdin)
class 'kdecore.Communication'
So I can only use the predefined values of the Communication enum (All,
AllOuput etc.). Is this a bug and is there a workaround to start a
KProcess() and only communicate with stdout and stdin and not stderr?
It appears that sip is doing strict checking for the KProcess.Communication
type, and KProcess.Stdin | KProcess.Stdout is not defined in that enum type.
Jim
[1]http://api.kde.org/3.5-api/kdelibs-apidocs/kdecore/html/classKProcess.ht
ml#31e69eb366082bb93bbdc31e6e281019
TIA,
w best regards,
Wilbert Berendsen
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] kdecore.KProcess.Communication enum not OR-able
On Saturday 12 April 2008 06:04, Wilbert Berendsen wrote:
Hi,
The KDE docs say that you can OR the values of the
kdecore.KProcess.Communication enum when start()ing a KProcess.[1]
However that seems not to be possible:
from kdecore import *
p=KProcess()
p.setExecutable('cat')
True
p.start(KProcess.NotifyOnExit, KProcess.Stdin | KProcess.Stdout)
Phil suggests that this:
p.start(KProcess.NotifyOnExit, KProcess.Communication (KProcess.Stdin |
KProcess.Stdout))
should work - I haven't tried it.
A couple of other notes: 1. This enum isn't available in KDE4 and 2. A lot of
the enums in KDE4/PyKDE4 (and Qt4) will require similar strict type-checking
(everything using QFlags).
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] dbus and PyKDE
KStandardAction doesn't seem to have the necessary c++ slot to python slot changes needed, this app doesn't work http://kubuntu.org/~jriddell/tmp/kapplication.py KStandardAction.close(self, self.hideMainWindow, self.actionCollection()) Try KStandardAction.close(self.hideMainWindow, self.actionCollection()) PyKDE and PyQt slot specifications only specify the slot method or function, not the slot's owner (first 'self') and method (self.hideMainWindow). Otherwise, if you were using the Qt syntax, the slot name would be a char *, not a method address. The close() method is included in KStandardAction inPyKDE (see sip/.kdeui/kstandardaction.sip). Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE extra/kde4xx suggestion
On Monday 07 April 2008 07:25, Adeodato Simó wrote: Hey Jim. Do you think it'd be possible to have the extra/kde4xx directories match only against the major (4.x) version, instead of the minor as well (4.x.y)? Speaking as a (Debian) packager, having the PyKDE packages become unbuildable each time a new minor version of KDE is uploaded is, uhm, inconvenient. If a new version makes it unbuildable, that would be an error, since configure.py should emulate the highest version it knows about. For example, if PyKDE was released for KDE 4.0.2 and you build against 4.0.3, configure.py should treat it as 4.0.2 still. I'd have to look at configure.py to see if that's still handled correctly. In that case, extra/kde402 should already exist, and the h files from that subdirectory would be used, so there shouldn't be a problem (if the new KDE version maintains binary compatibility with the old).. The most likely problem is that I forget to modify the manifest that's used to assemble the tarball and the latest extra/kde* gets omitted. Is there a reason why the extra/ subdirs could not be shared among minor releases? Because there's no guarantee they're the same h files in each version, or a new version won't introduce some problem that requires an h file be shipped with PyKDE instead of accessed from KDE's includes. The problems are either required h files that KDE doesn't install (and that can be errors by minor version), or in one case (the only one, I think), a file that needs to be modified to work with PyKDE.. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: [PyKDE] KConfigSkeleton/KConfigDialog combo not working
On Thursday 27 March 2008 08:32, Adeodato Simó wrote: Hello. I'm having trouble porting my PyKDE3 KConfigSkeleton/KConfigDialog: it behaves weird in KDE4. I'm attaching a very small sample program. The weird behavior I'm observing is: (a) on the first run, when no testrc file exists under ~/.kde, the value of MyOption is correctly set to False, but when I click on the Preferences button, the checkbox is checked (instead of not checked, at it'd correspond) (b) so I change in the dialog the value to True, when closing the dialog the LineEdit updates accordingly, and the option is written as true to the testrc file, but when I restart the program, it is set to False again Can you reproduce? Is there something wrong with my code? (With KDE 3 it worked just fine). I'm still looking into this - it doesn't look like it's going to fixed quickly. Just thought I'd let you know. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2-1 release available
On Friday 21 March 2008 11:24, Danny Pansters wrote: I've been trying to get this to build on FreeBSD, but the build fails with both gcc34 and gcc42: Sorry for the slow response - my email to Phil got delayed by a screwup in my mail system. Phil noticed that the methods in the error output all involved mode_t and time_t. PyKDE4 typedefs those as uint and long respectively in sip/kdecore/typedefs.sip. If FreeBSD is 2038-safe, then time_t is probably 64 bit. Would you be able to find the correct types for FreeBSD, fix typedefs.sip, and try a rebuild/recompile (you'll need to rebuild kdecore and kio at a minimum)? Let me know if that works. If it does, I'll figure out a permanent fix. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: [PyKDE] KConfigSkeleton/KConfigDialog combo not working
On Thursday 27 March 2008 08:32, Adeodato Simó wrote: Hello. I'm having trouble porting my PyKDE3 KConfigSkeleton/KConfigDialog: it behaves weird in KDE4. I'm attaching a very small sample program. The weird behavior I'm observing is: (a) on the first run, when no testrc file exists under ~/.kde, the value of MyOption is correctly set to False, but when I click on the Preferences button, the checkbox is checked (instead of not checked, at it'd correspond) (b) so I change in the dialog the value to True, when closing the dialog the LineEdit updates accordingly, and the option is written as true to the testrc file, but when I restart the program, it is set to False again Can you reproduce? Is there something wrong with my code? (With KDE 3 it worked just fine). Progress report: OK - I figured out what's wrong. Now I have to figure out how I want to fix it permanently (affects most of the KConfigSkeletonItem subclasses - Item*) I should have a new release up sometime next week. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2-1 release available
On Saturday 29 March 2008 09:25, you wrote: On Friday 28 March 2008 19:50:04 Jim Bublitz wrote: On Friday 21 March 2008 11:24, Danny Pansters wrote: I've been trying to get this to build on FreeBSD, but the build fails with both gcc34 and gcc42: Sorry for the slow response - my email to Phil got delayed by a screwup in my mail system. Phil noticed that the methods in the error output all involved mode_t and time_t. PyKDE4 typedefs those as uint and long respectively in sip/kdecore/typedefs.sip. If FreeBSD is 2038-safe, then time_t is probably 64 bit. Would you be able to find the correct types for FreeBSD, fix typedefs.sip, and try a rebuild/recompile (you'll need to rebuild kdecore and kio at a minimum)? Let me know if that works. If it does, I'll figure out a permanent fix. Jim Alright, this works: --- typedefs.sip.orig 2008-03-29 15:03:08.0 +0100 +++ typedefs.sip.new2008-03-29 17:12:08.0 +0100 @@ -20,11 +20,11 @@ // You should have received a copy of the GNU General Public License // along with this program. If not, see http://www.gnu.org/licenses/. -typedef uint mode_t; +typedef ushort mode_t; -typedef long time_t; +typedef int time_t; -typedef ulong size_t; +typedef uint size_t; typedef int ssize_t; @@ -36,7 +36,7 @@ typedef uint WFlags; -typedef long off_t; +typedef qlonglong off_t; typedef uint uid_t; For completeness: FreeBSD typedefs [qglobal.h] [on i386] unsigned int size_t [uint] [uint32_t] inttime_t [int] [int32_t] intssize_t [int] [int32_t] intpid_t [int] [int32_t] unsigned short mode_t [ushort][int16_t] long long off_t [qlonglong] [int64_t] unsigned int uid_t [uint] [uint32_t] unsigned int gid_t [uint] [uint32_t] Why are you not getting these from qplatformdefs.h but instead redefine them? Because sip, when generating code, doesn't have access to any h files, so typedefs need to be provided in a .sip file. But thanks for the pointer to the h file - I wasn't aware of it. I get exactly one warning during compile, should this be worrying (dont think so): c++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -fno-strict-aliasing -pipe -Wall -W -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde402 -I/usr/local/kde4/include -I/usr/local/include/QtCore -I/usr/local/include/QtGui -I/usr/local/include/QtXml -I/usr/local/include/QtSvg -I/usr/local/kde4/include/solid -I/usr/local/kde4/include/kio -I/usr/local/kde4/include/kfile -I/usr/local/kde4/include/kssl -I/usr/local/include/python2.5 -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I/usr/local/include -o sipkioKIOJobUiDelegate.o sipkioKIOJobUiDelegate.cpp sipkioKIOJobUiDelegate.cpp: In function `PyObject* meth_KIO_JobUiDelegate_askFileRename(PyObject*, PyObject*)': sipkioKIOJobUiDelegate.cpp:747: warning: converting of negative value `-0x1' to `long long unsigned int' sipkioKIOJobUiDelegate.cpp:748: warning: converting of negative value `-0x1' to `long long unsigned int' That happens because KDE programmers assign default argument values = -1 for unsigned types, and I've never been consistent in correcting that in the sip files. I should probably add a fix during my code generation from the h files, but it becomes a problem because unsigned long long, for example, can be written half a dozen different ways, and KDE uses all of them, plus typedefs.. Anyway, thanks for the hint. If it's tedious to fix it on your end, it's no problem for me to just patch typedefs.sip in the freebsd port. What does uname report for FreeBSD? I can check for that and swap in the correct typedefs.sip. I have some other fixes, so it'll be a few days before I release a tarball. If you want to go ahead and substitute a FreeBSD typedefs.sip for now, that's fine. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] dbus and PyKDE
On Thursday 27 March 2008 10:11, Jonathan Riddell wrote: I'm trying to get a printer applet into KDE (see kde-core-devel), however I can't actually use pyKDE because oxygen style and KApplication load QtDbus which causes the application to freeze when I'm using python-dbus. For example this app freezes when using KApplication but not when using QApplication. http://kubuntu.org/~jriddell/tmp/minimal.py Does anyone have any ideas on how to work around this? I haven't ignored this - I just need to rebuild PyQt with dbus support to check it out (and had another bug fix in the queue).. I also don't have the Python cups module, and can't seem to find it for SuSE 10.3 (download.opensuse.org is also down at the moment). Any idea where I can find the source for it? I doubt it's the problem though, but won't know until I finish rebuilding. QtDBus shows up if you ldd any of the PyKDE4 modules, but it's not expressly linked by PyKDE4, so one of the Qt or KDE libs is sucking it in. And - menus don't work in PyKDE4 with the Oxygen theme. Haven't gotten to that yet either (and am not looking forward to it). Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] dbus and PyKDE
On Thursday 27 March 2008 10:11, Jonathan Riddell wrote: I'm trying to get a printer applet into KDE (see kde-core-devel), however I can't actually use pyKDE because oxygen style and KApplication load QtDbus which causes the application to freeze when I'm using python-dbus. For example this app freezes when using KApplication but not when using QApplication. http://kubuntu.org/~jriddell/tmp/minimal.py Does anyone have any ideas on how to work around this? With QApplication, I get: Traceback (most recent call last): File minimal.py, line 63, in module applet = PrinterApplet() File minimal.py, line 33, in __init__ bus_name = dbus.service.BusName (PDS_OBJ, bus=bus) File /usr/lib/python2.5/site-packages/dbus/service.py, line 113, in __new__ retval = bus.request_name(name, name_flags) dbus.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection :1.102 is not allowed to own the service com.redhat.NewPrinterNotification due to security policies in the configuration file That's the same point at which the program hangs using KApplication. (That's also without Oxygen, which is a different problem). KApplication uses QtDBus, so there's no eliminating that. That should ensure the application gets automatically registered though. You can change the organization domain via KAboutData - didn't try that though. I guess what I'd try is some simpler stuff - see if you can communicate via DBus at all, query for available services - in general, see if anything works. If it doesn't, maybe it'll turn up something that provides more insight. Send me whatever you come up with (working or not) and I'll see where I can go from there. I really have no understanding of the whole subject and it looks like a few weeks of learning curve for me to dig into it much more. Doesn't look like a quick fix is available from this end, but I'm certainly willing to go at it. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] dbus and PyKDE
On Thursday 27 March 2008 10:11, Jonathan Riddell wrote: I'm trying to get a printer applet into KDE (see kde-core-devel), however I can't actually use pyKDE because oxygen style and KApplication load QtDbus which causes the application to freeze when I'm using python-dbus. For example this app freezes when using KApplication but not when using QApplication. http://kubuntu.org/~jriddell/tmp/minimal.py Does anyone have any ideas on how to work around this? I get the same result for KApplication as QApplication (exception, no hang) if I make set_as_default=False in the statement that sets up mainloop. Seems to make no difference which way it's set with QApplication. Hope that helps - I still have a pretty limited understanding of the whole thing. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KProcess setUsePty not there...
On Wednesday 02 April 2008 08:00, Wilbert Berendsen wrote: Hi, I want to run a program that insists on reading from a terminal using KProcess (from within PyKDE), but it seems KProcess::setUsePty() does not exist: Python 2.5.1 (r251:54863, Mar 26 2008, 22:37:08) [GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2 Type help, copyright, credits or license for more information. from kdecore import * p=KProcess() p.setUsePty(3,False) It's an error in not providing a #define for a conditional in the h file when generating PyKDE. You can fix it in sip/kdecore/kprocess.sip by changing this (near line 193): %If ( KDE_3_2_0 - KDE_3_4_0 ) void setUsePty (KProcess::Communication, bool); KPty*pty () const; %End to this: %If ( KDE_3_2_0 - ) void setUsePty (KProcess::Communication, bool); KPty*pty () const; %End and then rebuild with python configure.py -lkdecore make su -cmake install Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: [PyKDE] KConfigSkeleton/KConfigDialog combo not working
On Thursday 27 March 2008 08:32, Adeodato Simó wrote: Hello. I'm having trouble porting my PyKDE3 KConfigSkeleton/KConfigDialog: it behaves weird in KDE4. I'm attaching a very small sample program. The weird behavior I'm observing is: (a) on the first run, when no testrc file exists under ~/.kde, the value of MyOption is correctly set to False, but when I click on the Preferences button, the checkbox is checked (instead of not checked, at it'd correspond) (b) so I change in the dialog the value to True, when closing the dialog the LineEdit updates accordingly, and the option is written as true to the testrc file, but when I restart the program, it is set to False again Can you reproduce? Is there something wrong with my code? (With KDE 3 it worked just fine). Thanks in advance, If you add some print statements you can see what's happening, but not why - haven't figured that out yet. In Preferences.__init__(), the value is False after both the addItemBool and readConfig() calls. But on return from the Preferences() call in the main window __init__, the value is True. Obviously , that's not right. Otherwise, I'm still looking into it. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] error building PyKDE 4.0.2-1 - QTDIR not respected
On Monday 24 March 2008 07:31, Giacomo Lacava wrote: Hi, I can't build PyKDE 4.0.2-1, even though KDE 4.0.2 is installed. It seems it cannot find the Qt include files, even though QTDIR is set to a symbolic link (/home/pyqt-trunk/share/qt4) pointing to the correct /home/pyqt-trunk/share/qt4.3.3. The mentioned includes That's fixed in PyKDE4-4.0.2-2, which is up at riverbankcomputing.com. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2-1 release available
On Friday 21 March 2008 11:24, Danny Pansters wrote: I've been trying to get this to build on FreeBSD, but the build fails with both gcc34 and gcc42: /usr/local/kde4/include/karchive.h:279: note: virtual bool KArchive::doWriteDir(const QString, const QString, const QString, mode_t, time_t, time_t, time_t) /usr/local/kde4/include/karchive.h:297: note: virtual bool KArchive::doWriteSymLink(const QString, const QString, const QString, const QString, mode_t, time_t, time_t, time_t) /usr/local/kde4/include/karchive.h:316: note: virtual bool KArchive::doPrepareWriting(const QString, const QString, const QString, qint64, mode_t, time_t, time_t, time_t) sipkioKArchive.cpp:1361: error: cannot allocate an object of abstract type 'sipKArchive' sipkioKArchive.cpp:28: note: since type 'sipKArchive' has pure virtual functions sipkioKArchive.cpp:1373: error: cannot allocate an object of abstract type 'sipKArchive' sipkioKArchive.cpp:28: note: since type 'sipKArchive' has pure virtual functions *** Error code 1 Stop in /usr/home/danny/PyKDE4-4.0.2-1/kio. *** Error code 1 Stop in /usr/home/danny/PyKDE4-4.0.2-1. That's really interesting, because it builds fine here, but it looks like the sip-generated code might be incorrect - the karchive.sip file correctly flags the virtual methods. I'll have to check with Phil - not sure what's going on with this. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QtDBus not wrapped, trouble using dbus-python (communication hangs)
On Thursday 13 March 2008 15:50, Adeodato Simó wrote: * Phil Thompson [Thu, 13 Mar 2008 22:03:08 +]: You need to create the QApplication before the main loop. Oh, changing that makes the example work, thank you. However, if I change QApplication to KApplication, I get this error: QMutex::lock: Deadlock detected in thread -1210529600 And the application hangs. Any ideas? Setting some of the fields in KAboutData also sets some info that DBus uses (name, domain info?) - setting it incorrectly (like putting the .py extension on the name) also causes problems. I'd also try changing QMainWindow to KMainWindow or KXmlGuiWindow. Other than that (actually including that), I have no clue. Haven't seen any KDE docs on it either, although you could try kde.org. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] [PyKDE] One more issue with qt4 includes
On Wednesday 12 March 2008 06:00, Adeodato Simó wrote: Well, I've now seen in the 4.0.2-1 tarball ChangeLog that says: Allow for separate dir for Qt includes in configure.py But I can't find that option. It would be indeed very handy. It should pickup the Qt include directories automatically via PyQt4.pyqtconfig.py. There is no option for setting that value in PyKDE4, because it should be the same path as in PyQt4. Let me know if it's not working - I have Qt and KDE includes in the same directory, so don't test it. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4-4.0.2-1 release available
The PyKDE4-4.0.2-1 release is now available at riverbankcomputing.com. It should fix various install issues, including correct variable typing in some handwritten KIO.MetaData code, correctly obtaining the Qt include path from your PyQt4 install, and it now installs pykdeuic. It also provides a PyKDE4.api file for use with eric4. Bug reports always appreciated. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] [PyKDE] One more issue with qt4 includes
On Wednesday 12 March 2008 09:09, Adeodato Simó wrote: * Adeodato Simó [Wed, 12 Mar 2008 14:00:41 +0100]: Well, I've now seen in the 4.0.2-1 tarball ChangeLog that says: Allow for separate dir for Qt includes in configure.py But I can't find that option. It would be indeed very handy. Ah, I see it's in configure.template, but not in configure.py. Arghh! I don't know how that happened. Attached is a correct configure.py. I'll update the tarball. Jim configure.py Description: application/python ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4-4.0.2 release
PyKDE4-4.0.2 is now available at riverbankcomputing.com. It includes some minor fixes to problems that were preventing PyKDE4 from building against KDE 4.0.2, the addition to kdecore of some global functions for retrieving version info about KDE and PyKDE4 (see Using PyKDE4 in the documentation), and some additional changes to the docs. This release should build against any KDE4 version currently in release. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2 release
On Tuesday 11 March 2008 10:48, Detlev Offenbach wrote: I have a dual installation of KDE. KDE4 is installed alongside KDE3, which is my main desktop. The environment variable KDEDIR is set to /opt/kde3 (openSUSE 10.3). This makes configure.py to pick up KDE3 instead of KDE4. Here is an excerpt of the output. Thanks for the report - I don't have $KDEDIR set on any systems so didn't catch this problem (I think KDE discontinued it a while ago, although PyKDE3 continued to check for it). The workaround is already in place - use the -k switch on the configure.py command line to specify the correct KDE4 base directory (which I believe is now /usr for all distributions - even SuSE finally switched). Or set $KDEDIR to nothing temporarily. Outside of this problem, there should be no difficulty is running PyKDE3 and PyKDE4 simultaneously, or running PyKDE4 under KDE3 as the desktop (assuming KDE4 is installed). Any problems should be considered bugs. The fix will be in the next release - I've removed $KDEDIR from configure.py and added a check for KDE_VERSION_MAJOR == 4. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4 -4.0.2-1 release coming
The release today has a few bugs which need fixing. The fixes are already done, but I need to test compile before uploading a new release, and that takes awhile - I have PyKDE4 on a slow machine. I also have a couple more potential bugs to check out. Although compiling on that machine doesn't catch these particular bugs anyway, but at least it'll indicate I didn't break more stuff doing the fixes. The new tarball should be up in a day or two. Workarounds are on the mailing list. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2 release
On Tuesday 11 March 2008 11:39, Detlev Offenbach wrote: On Dienstag, 11. März 2008, Detlev Offenbach wrote: On Dienstag, 11. März 2008, Jim Bublitz wrote: PyKDE4-4.0.2 is now available at riverbankcomputing.com. It includes some minor fixes to problems that were preventing PyKDE4 from building against KDE 4.0.2, the addition to kdecore of some global functions for retrieving version info about KDE and PyKDE4 (see Using PyKDE4 in the documentation), and some additional changes to the docs. This release should build against any KDE4 version currently in release. Hi, I have another problem compiling latest release with KDE 4.0.2 (s. below). --- g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde402 -I/usr/include -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtXml -I/usr/include/QtSvg -I/usr/include/solid -I/usr/include/kio -I/usr/include/kfile -I/usr/include/kssl -I/usr/include/python2.5 -I/usr/share/qt4/mkspecs/default -I/usr/X11R6/include -o sipkioKIOMetaData.o sipkioKIOMetaData.cpp sip/kio/global.sip: In function ‘int convertTo_KIO_MetaData(PyObject*, void**, int*, PyObject*)’: sip/kio/global.sip:242: error: cannot convert ‘int*’ to ‘Py_ssize_t*’ for argument ‘2’ to ‘int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)’ And here is the fix. Line 242 of sip/kio/global.sip should read. #if PY_VERSION_HEX = 0x0205 Py_ssize_t pos = 0; #else int pos = 0; #endif With that change, PyKDE4 compiles fine. Correct - SIP_SSIZE_T is a macro that does the same thing. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.2 release
On Tuesday 11 March 2008 11:16, Detlev Offenbach wrote: On Dienstag, 11. März 2008, Jim Bublitz wrote: PyKDE4-4.0.2 is now available at riverbankcomputing.com. It includes some minor fixes to problems that were preventing PyKDE4 from building against KDE 4.0.2, the addition to kdecore of some global functions for retrieving version info about KDE and PyKDE4 (see Using PyKDE4 in the documentation), and some additional changes to the docs. This release should build against any KDE4 version currently in release. Hi, I have another problem compiling latest release with KDE 4.0.2 (s. below). --- g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_GUI_LIB -I. -I../extra/kde402 -I/usr/include -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtXml -I/usr/include/QtSvg -I/usr/include/solid -I/usr/include/kio -I/usr/include/kfile -I/usr/include/kssl -I/usr/include/python2.5 -I/usr/share/qt4/mkspecs/default -I/usr/X11R6/include -o sipkioKIOMetaData.o sipkioKIOMetaData.cpp sip/kio/global.sip: In function ‘int convertTo_KIO_MetaData(PyObject*, void**, int*, PyObject*)’: sip/kio/global.sip:242: error: cannot convert ‘int*’ to ‘Py_ssize_t*’ for argument ‘2’ to ‘int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)’ Around line 238 in sip//kio/global.sip change int pos = 0; to SIP_SSIZE_T pos = 0; It's a change in type from Python 2.4 to 2.5 - this seems to be the final instance, although I can't tell because I seem to get the correct type conversion when I compile and don't catch the error. SIP_SSIZE_T will work correctly for either Python version. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.0 release available
On Saturday 08 March 2008 08:34, Adeodato Simó wrote: * Jim Bublitz [Wed, 05 Mar 2008 09:46:33 -0800]: The first PyKDE4 tarball release is available at Riverbank Computing W00t. This release will build against KDE 4.0.0 or 4.0.1 FWIW it fails with 4.0.1 because that version has: #define KDE_VERSION_MINOR 0u in kdeversion.h, as a workaround to a CMake bug, and configure.py chokes on it. I'll have to look into that. I thought I upgraded the kdelibs-devel package when I upgraded to 4.0.1, but my header files are still 4.0.0. In addition, the source file is now kdeversion.h.cmake, so it doesn't get picked up in generating PyKDE (different than the configure.py problem. I'll need a little time to get all of that straightened out. Thanks for your work! My pleasure. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4-4.0.0 release available
On Saturday 08 March 2008 08:34, Adeodato Simó wrote: * Jim Bublitz [Wed, 05 Mar 2008 09:46:33 -0800]: The first PyKDE4 tarball release is available at Riverbank Computing W00t. This release will build against KDE 4.0.0 or 4.0.1 FWIW it fails with 4.0.1 because that version has: #define KDE_VERSION_MINOR 0u in kdeversion.h, as a workaround to a CMake bug, and configure.py chokes on it. OK - I have a 4.0.2 install going and got as far as getting the kdelibs-devel h files installed, and kdeversion.h does have that problem. I'll catch that the other small bugs reported so far and do a 4.0.2 release sometime next week hopefully. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE-3.16.1 release
A new PyKDE3 release is up at Riverbank Computing: http://www.riverbankcomputing.co.uk/pykde/index.php This release removes the need to patch the PyKDE3 source code, and should also remove any of the konsole_part issues some people were having (konsole_part is no longer supported). The release also requires a sip version of 4.7.0 or later (preferably the most recent release - 4.7.4 - which is also available at Riverbank). I've decided to upgrade PyKDE3 to the latest KDE releases, through 3.5.9. The current release should build against any PyKDE3 released version, and there probably isn't a lot of new stuff in the more recent KDE releases. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4-4.0.0 release available
The first PyKDE4 tarball release is available at Riverbank Computing http://www.riverbankcomputing.co.uk/pykde/index.php This release will build against KDE 4.0.0 or 4.0.1 (the difference between the two is a total of 3 new methods). With the exception of a couple of small bug fixes, this release should be the same as the kdebindings releases that come with KDE4, maintained by Simon Edwards. This release includes a full set of documentation based on the C++ documentation included in the KDE4 h files. It also includes a tutorial and a few small example programs. It also includes a framework for viewing live examples and documentation simultaneously (pykdedocs), based on the pykdesampler Troy Melhase began for PyKDE3. The documentation, examples and viewer can be installed separately if you already have PyKDE4 installed. The viewer requires PyKDE4. Contributions of additional example programs or tutorials would be greatly appreciated. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: PyQt
On Wednesday 05 March 2008 16:29, Jon Chambers wrote:
Thanks for the speedy responses!
I'm now trying to create a non-paintEvent function that calls an update if
necessary. But now when i do
self.connect(self.timer, QtCore.SIGNAL('timeout()'), self.pollJoysticks())
Remove the parens from self.pollJoysticks () - you want the address of the
method, not to call the method. Should be:
self.connect ( ... self.pollJoysticks)
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 on Windows
On Thursday 07 February 2008 06:12, Saro Engels wrote: Hello all, As some of you might already know KDE applications are ported to MS Windows. Since I am currently trying to port the module scripts, I came by the kdebindings module as well. I added some scripts for sip and PyQt4 which seem to work on the first glance (they are supposed to work with the Qt version we distribute). Then I tried to get PyKDE4 working and the build process already crashed while cmake'ing. I fixed some issues (some are still local here) but then I decided to ask here first. So are there any efforts in making PyKDE4 working on Windows (and/or Mac)? Where is development for PyKDE4 going on and how can we contribute (that means: is committing to KDE subversion the right way)? I was very impressed by PyQt and I hope PyKDE can get into a similar state in the near future. If someone wants to tackle PyKDE4 for Windows, feel free to have at it. The only other environment I have access to is Win98, and I don't think there's a lot of demand for that port (or interest on my part to code for Windows). No Macs here either. It should be possible to configure PyKDE4 for either of those platforms and incorporate the conditionals into either the KDE SVN version or my tarballs (if I ever get one put together). Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 question
On Tuesday 05 February 2008 01:41, Adeodato Simó wrote: * Jim Bublitz [Sun, 03 Feb 2008 09:52:40 -0800]: Hello Jim. I'm still working on my release (upgrading tools and documentation generation) Is this release intended to replace the current code in KDE's SVN? If so, is it somewhere public? If it's somewhat useable already, I wouldn't mind testing to see if it works fine for me, and/or solves the problems I reported with the current code [1 and 2]. Eventually Simon (who maintains the SVN code) and I will probably sync our versions. The way this is developed is that I write code to generate PyKDE, so for example what I'm finishing up now is some small details about scoping arguments (sip requires more explicit scoping than C++) and generating %ConvertToSubClassCode (which handles class promotion, somewhat like casting). There also needs to be some code to generate documentation. Those affect all modules, so there really isn't any pre-release or alpha version - PyKDE either exists or it doesn't. Once all that's complete, I need to find any bugs releated to sip generation, compilation or linking and the same generally applies there - it either works or it doesn't (for example, a single undefined symbol - which occurs fairly often on new releases - will prevent a module from loading). Once that's all done, I'll have a release - probably in a month or a little longer. At that point, Simon can look at whether he wants to switch to the new code generation tool (which is both faster and more accurate - less manual fixup needed), and we can sync versions. There are some changes from the betas I looked at to the KDE 4.0.0 release in terms of KConfig related code, so that may be where that problem lies. Menu stuff I'd have to look at - I have done some code with older (pre-release) KDE versions and haven't noticed any problems there, but will check it out when I have stable/complete code. Jim [1]: KConfig crash: http://www.riverbankcomputing.com/pipermail/pyqt/2008-January/018232.html [2]: Text now showing up in menus with Oxygen: http://www.riverbankcomputing.com/pipermail/pyqt/2008-January/018164.html Thanks for your work, ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A couple of question about PyKDE4
On Tuesday 05 February 2008 11:49, Torsten Marek wrote: Hi all, Debian's KDE team has started to package KDE 4.0 quite some time ago, and they have asked me if I had plans to package PyKDE 4.0. Before I start out with PyKDE4, I have a couple of questions: - what is the preferred build system? cmake or configure.py? Will any of these build system vanish in the future? - are there going to be separate releases of PyKDE4, or will everything be coordinated with the KDE releases? - is there any high-level documentation about krosspython? Forgive my ignorance, but I've never come across it. (I'd *guess* that it's for embedding PyKDE4 scripts as components in KDE programs) Hi Torsten - On Tuesday 15 January 2008 08:40, you wrote: Hi Jim, Debian's KDE team has started to package KDE 4.0 quite some time ago, and they have asked me if I had plans to package PyKDE 4.0. It's been quite some time since I've done serious work with PyQt and PyKDE, my packages are in maintenance mode mostly. I'd actually like PyKDE4 to be an opportunity to get a good look at KDE 4.0 and probably do some GUI programming again. Before I start out with PyKDE4, I have a couple of questions: - what is the preferred build system? cmake or configure.py? Will any of these build system vanish in the future? I haven't looked lately, but I think Simon is using cmake with the KDE SVN version. I'll be continuing to use configure.py. I'm pretty sure Simon will want to go with/stay with cmake, and that I'll stay with the configure.py setup. The latter depends on sip support, so if Phil changes that, I'll have to change my setup/install stuff, but it's likely I'll stay with some kind of Python scripting. Of course nothing lasts forever, but I don't see anything that would change my mind in the near future. - are you going to make separate releases of PyKDE4, or will everything be coordinated with the KDE releases? I'll probably do separate releases - I'm behind again and won't be releasing for a month or two. What Simon has put in KDE SVN should be current and reasonably complete, and will likely stay that way. We're a little out of sync at the moment because he's still using the original PyKDE tools (presip + scripts) to develop PyKDE. My holdup is largely finishing a new toolset for PyKDE based on Ply (Python Lex-Yacc) rather than a handwritten parser. There's also a better set of documentation and a documentation viewer (pykdedocs) that integrates tutorials, example programs, docs and will let you browse other docs (Python, PyQt, Qt, KDE, etc) locally or online. I don't know if Simon has included that yet. The viewer software is all PyKDE4 based, so I have had a chance to test out a lot of the GUI and KParts/KHTML related stuff, and it was working very nicely. The Ply-based tools will make it a lot easier to develop docs from the KDE doc set and is a much easier to maintain bunch of code. The only thing missing in PyKDE4 is Phonon support, which is a little messy (or was last time I looked). - is there any high-level documentation about krosspython? Forgive my ignorance, but I've never come across it. (I'd *guess* that it's for embedding PyKDE4 scripts as components in KDE programs) Kross is for embedding Python scripts in KDE apps - that could use PyKDE (I think), but isn't dependent on it or sip. I think Sebastian Kugler ([EMAIL PROTECTED]) is the lead developer - we've exchanged a few messages (email or at dotKDE - don't recall which), but there isn't any connection between Kross and PyKDE. I haven't seen any Kross docs, but haven't looked in a while (that's about the third or fourth time I've said something like that - I am a little behind on most of this). Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 question
On Sunday 03 February 2008 08:25, Detlev Offenbach wrote: Hi, I'd like to include KDE4 support into eric4 (4.2.x development) similiar to the way it was for eric3/PyKDE3. The docs for PyKDE4 give details about how to setup a KPrinter instance. However, I could not find it. Can anybody give an example on it's usage. From the KDE docs for KDE 4.0.0:: libkdeprint has been replaced by enhanced printing support in Qt 4. Qt 4.3 is still lacking in a print preview feature and a customisable print dialog. KPrintPreview (kutils) provides the former, and KdePrint::createPrintDialog() (kdeui) provides the latter, at least for Qt 4.3.2 onwards. --- I'm not sure if Simon has included these in the kdebindings version. I'm still working on my release (upgrading tools and documentation generation), but the dialog and preview will eventually be included in that. But there no longer is a kdeprint module. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] What do I import in pykde 3.16 to access PyKDE.versionString ()?
On Thursday 17 January 2008 10:42, Dog Walker wrote: The documentation says that both KDE.versionString and PyKDE.versionString are available since 3.11. I find KDE.versionString in kdecore on PyKDE 3.16 but cannot locate PyKDE.versionString. What should I import to access this function? It apparently got left out - it should be in kdeversion.sip.. However, you should have a copy of pykdeconfig in /site-packages, or wherever PyKDE has been installed (you will have for sure if you compiled - can't say if packagers install it). You can find the version there: import pykdeconfig cfg = pykdeconfig.Configuration () cfg.pykde_version 200450 cfg.pykde_version_str '3.15.2' pykde_version is the hex representation - would be 0x030f02 in this case (which should equal decimal 200450). I'm apparently running an older version of PyKDE on this box. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Changing systray icon while handling signal
On Thursday 17 January 2008 08:27, Dog Walker wrote: Using pyKde3 I have a KSytemTray application. I want to change the systray icon (and tooltip) when I begin handling a menuitem and change again before returning. It appears that the icon/tooltip is only set after returning to pyKde. Can I do what I want? How? Assuming you're using KSystemTray, KSystemTray.setPixmap (pix) sets the icon to pix, whatever it's value is when called. See PyKDE/examples/systray.py Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Changing systray icon while handling signal
On Thursday 17 January 2008 21:26, Dog Walker wrote: On Jan 17, 2008 2:23 PM, Jim Bublitz [EMAIL PROTECTED] wrote: On Thursday 17 January 2008 08:27, Dog Walker wrote: Using pyKde3 I have a KSytemTray application. I want to change the systray icon (and tooltip) when I begin handling a menuitem and change again before returning. It appears that the icon/tooltip is only set after returning to pyKde. Can I do what I want? How? Assuming you're using KSystemTray, KSystemTray.setPixmap (pix) sets the icon to pix, whatever it's value is when called. See PyKDE/examples/systray.py Jim [...] I have failed to make myself clear. I have an icon in the systray with a menu. One of the the menuitems is do_time_consuming_task. When that menu item is selected by the user, function do_time_consuming_task() runs. That function tries to set the systray icon to busybusy.png and set the tooltip to TCB'ing. Immediatley after doing the icon change and tooltip code, the function begins a long task. After the long task end, the function changes the systray icon and tooltip text back to what it was. The function returns. The icon/tooltip does not change during the running of the function. Neither is the icon in the systray repainted if covered or when switching desktops. - Anyway I solved the icon change part. The long running function could be invoked from the menu or by a timer interrupt. So the first time the long running function is entered, the icon is changed and a short timer is set to invoke the function. The function returns, is reentered, it does its long running thing, sets another icon and restores the normal timer interval. Setting a tooltip to show during the long running function is worthless because the app loop must be running to show it. For the same reason, the icon disappears in the systray if the user switches desktops (all the systray icons are erased and must be repainted). You can call your application object's processEvents() method (see QApplication docs) or maybe set other timers to do redraws. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] simpler 'connect' function
Just jumping in on the thread here,not replying to anyone in particular. I modified (polite word for hacked up) an example program written by Troy Melhase for PyKDE3, and what he had done was kind of interesting, I thought: sigClicked = SIGNAL (clicked ()) class MainWindow (KMainWindow): def __init__ (self, parent): ... self.connect (self.button, sigClicked, self.buttonClicked) The program uses 15-20 signals, all defined and referenced as above. It'd seem like it would be possible to have PyQt/PyKDE automatically do the SIGNAL definitions (as predefined constants, for example SIG_CLICKED) and then just reference them as in the connect statement above. I don't know if any checking could be performed to validate that 'self.button' really emits a 'sigClicked' or 'clicked ()' signal. I also don't know if I'd really advocate this or if I'd do it this way again, but it was a nice way to organize the program and still keeps things readable - just thought I'd throw it out as one alternative. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] [PyKDE4] Default value for the second argument of KAction.setShortcut() does not seem to work
On Saturday 12 January 2008 02:40, Simon Edwards wrote:
Hi,
Adeodato Simó wrote:
This one time, I'm finding that KAction.setShortcut() can't work in
Python without passing a value for the second argument, whereas this
works in C++. Any chance you'd know why? Thanks.
Looks like a bug in PyKDE4. The second arg doesn't have a default value
like in the C++ version. I'll try to get this fixed in 4.0.1.
It's a feature :)
More accurately it's a feature in presip that won't handle the typesafe
enumerator expression that's the default value. You can try adding it
manually for both setShortcut methods in kaction.sip. Not sure if sip will
handle it, but I think it will.
The current behavior for Python is covered in the docs (no default value is
shown). It should be covered in the 'Getting Started' tutorial too, but it
looks like I didn't finish writing the last section of that.
This:
-8-
#! /usr/bin/env python
from PyKDE4 import kdeui
action = kdeui.KAction(None)
action.setShortcut(kdeui.KShortcut('Ctrl+F'))
Add the second arg like this (and close your eyes):
action.setShortcut(kdeui.KShortcut('Ctrl+F'),
kdeui.KAction.ShortcutTypes( \
kdeui.KAction.ShortcutTypes(kdeui.KAction.ActiveShortcut) | \
kdeui.KAction.ShortcutTypes(kdeui.KAction.DefaultShortcut)))
This fix will work in the future and has the same effect as the fixed
version.
mmm... it would be nice if PyQt4's QFlags() accepted a uint mask in its
constructor. If would save a lot of ugly Python code, for the price of a
little bit of runtime type safety...
You can save some verbosity by doing
from PyKDE4.kdeui import KAction
and then define some constant
default = KAction.ShortcutTypes
(KAction.ShortcutTypes(KAction.ActiveShortcut) \
|.KAction.ShortcutTypes.KAction.DefaultShortcut))
and use that in the method call.
At the moment I don't think there's any way to get around the type safety
stuff. KDE4 expects a class object for the second argument.
---
I should get together an update for you (Simon) - I've been tied up on a lot
of other stuff the last few months and haven't made much progress. The new
code generator is about 85% complete. I believe it handles the problem above,
but it needs about another month or so to complete, and it looks like a few
more weeks before I can get back to working on it.
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde4 using KConfig XT - tutorial
On Saturday 12 January 2008 02:09, Simon Edwards wrote: Hi, Peter Liedler wrote: I am trying to autogenerate a configuration dialog with a KConfigSkeleton. I just can't get it working. What went wrong? Can you post me a sample, tutorial or something else on how to call a config dialog in pykde4? Not that I'm aware of. I tried it with a .kcfg file as described in the tutorials on kde.org, but there was no success. If I remember rightly, the kconfig stuff in KDE uses a lot of C++ templates which makes bindings difficult. There is a good chance that the config stuff is incomplete. Jim appears to be off-line for a while now and I've had to try keeping the kconfig stuff up to date and working. If it is screwed up, then it is probably my fault. :) The template stuff (KConfigSkeleton.Item* classes) is all implemented in PyKDE4 and should work. It doesn't include the patches from PyKDE3 that sort of simulated pass by reference/reference variables for those classes - those have been dropped. Someone had promised to write a tutorial in exchange for some patches, but it was never done. I've never used KConfigSkeleton and have no idea how to use it., and therefore no way to test it. There is some config file generation stuff in KDE4, but I haven't looked much at that either - it seemed like it might be possible to get it to work for PyKDE4 (but I'm not sure about that). I would suspect that's what's not working. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] konsoleFactory::className()
On Friday 11 January 2008 06:48, D.H.J. Takken wrote: Hi, Is there anyone having a look at this issue please? I was asked which PyKDE I am using. I replied to the list, but no response ever since You can try editing configure.py. Find any reference assigning a value to 'opt_konsolepart' and set it to False. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] konsoleFactory::className()
On Friday 11 January 2008 15:41, D.H.J. Takken wrote: Op Friday 11 January 2008 17:56:29 schreef Jim Bublitz: On Friday 11 January 2008 06:48, D.H.J. Takken wrote: Hi, Is there anyone having a look at this issue please? I was asked which PyKDE I am using. I replied to the list, but no response ever since You can try editing configure.py. Find any reference assigning a value to 'opt_konsolepart' and set it to False. The command cat configure.py | grep konsole gives me: makefile.extra_libs.append (konsolepart) target = os.path.join (opt_kdelibdir, kde3, libkonsolepart.so) symlink = os.path.join (opt_kdelibdir, libkonsolepart.so) No trace of anything called opt_konsolepart... OK - apparently the update (-x switch) never got uploaded - my fault. What you have should be identical to PyKDE 3.16.0 from riverbankcomputing.com. In configure.py: Try commenting out the if extra_lib ... block that contains the first line above (makefile.extra_libs ..., around line 733), then locate the if kde_version ... block that contains the second two lines above, and comment out the entire if block. (around line 765) That should eliminate all of the konsolePart modifications to the Makefile without affecting anything else.. IIRC the problem arose because of changes in distributions after adding the konsolePart support that had been requested. If it doesn't build with your distribution, there isn't any (simple) way to provide konsolePart support, which you probably won't miss anyway. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] konsoleFactory::className()
On Thursday 03 January 2008 10:40, D.H.J. Takken wrote: Op Wednesday 02 January 2008 19:05:56 schreef Jim Bublitz: On Wednesday 02 January 2008 06:38, D.H.J. Takken wrote: Hi, Are there any developers on this list that can have a look at this issue? Thanks! Try adding the -x switch to configure.py command line. configure.py is supposed to detect whether konsolePart support is available (it isn't in most later versions) automatically. Hmmm... The -x switch does not seem to exist: python configure.py -k /usr/kde/3.5 -x Usage: python configure.py [-h] [-c] [-d dir] [-g] [-j #] [-k] [-n dir] [-o dir] [-r] [-u] [-v dir] [-z file] What version of PyKDE? Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Rejoice, for PyKDE4 has landed in KDE SVN
On Monday 12 November 2007 10:41, Adeodato Simó wrote: * Simon Edwards [Mon, 03 Sep 2007 08:37:52 +0200]: Almost all classes in kdelibs are covered, except Phonon which is waiting on imporved namespace support in SIP before we can add support. Hello. I'm not really following KDE4 development, but I'd like to know how this is going. I'm the author of an audio player for KDE using PyKDE and I'd really love to see bindings to Phonon. I currently use GStreamer, and it gives me a lot of headaches. Do you have any status update for Phonon bindings? (I doubt there's much I could do to help, except when a first version is available, porting my app and verifying that at least my use case works.) There will probably be Phonon bindings and they'll probably be in the initial PyKDE4 release. They aren't in the beta stuff yet because the Phonon interface has been changing and there are some issues with it that require handwritten code (nearly everything else is generated automatically). The support needed in sip either was provided or I fixed the error in PyKDE4 that was the problem (might be a little of both), but there are still a few other problems due to the way templates are used in the C++ code. The other concern would be that the initial Phonon bindings may be buggy until someone writes some code to use them and discovers the bugs. I'll try to make a point of announcing here when the Phonon bindings hit SVN (or a tarball) so that you can try them out before release (if the timing works out that way). Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] kapplication not quiting
On Monday 29 October 2007 08:04, Andres Riancho wrote: Marcos, On 10/29/07, Marcos Dione [EMAIL PROTECTED] wrote: On Mon, Oct 29, 2007 at 09:36:14AM -0300, Andres Riancho wrote: And then, I try to kill the object like this: application.processEvents() application.exit(0) application.quit() del application But when I try to create a new kapplication using the same lines I specified above, I get this error message: Qt debug: QApplication: There should be max one application object can you tell us where this code is run? can you post some more code, or even build a smaller example? While I was trying to create a smaller example, I found another way of creating a crash. Please see the attached example. I will try to create an example that returns QApplication: There should be max one application object and i'll get back to you. I don't have any supporting documentation on this (there may be something on the list two or three years ago or maybe even farther back), but I ran into a similar problem developing unit tests for PyKDE, where I wanted to construct and then tear down KApplication instances. The end result was that it isn't something you can do reliably within a single program. You either need to construct a single instance and reuse it, or fork a new process for each KApplication instance and then destroy the process when done with it.. I believe this is a KDE or Qt feature and not specific to PyKDE (and the error msg above is from Qt). I'm not really sure why it should be the case, but can think of a number of possible reasons. I'm fairly sure though that I did trace it back to some documentation that indicated it wasn't possible. Someone else can let me know if my memory is faulty. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt book Rapid GUI Programming with Python and Qt now available
On Thursday 25 October 2007 10:19, David Boddie wrote: On Thu Oct 25 12:56:25 BST 2007, Andreas Pakulat wrote: In Amazon Germany its even 63.3 euros, which makes about 90 us$, thats almost double the normal price of the book as shipped in the US. I could find it quite a bit cheaper at libri.de, its 42,74 euro there, which is still more than 10 dollar more than the original price from prentice hall. If I buy directly from prentice hall, I'd pay 67$ including shipping, AFAICS I thought I'd see if I could find a lower price in the Euro zone, or a price outside that would correspond to a lower price. I used kelkoo.co.uk first, then tried their service in other regions. Here's what I found: United Kingdom: 23.75 GBP (~34 EUR) http://books.theregister.co.uk/catalog/browse.asp?ref=863830 Apparently, shipping would be free if the price was over 25 GBP. :-( Otherwise, it appears that delivery to Europe is 7.95 GBP (~11 EUR)! (http://books.theregister.co.uk/info/payment_delivery.asp) Norway: 297 NOK (~38 EUR) http://www.capris.no/product.aspx?isbn=0132354187 Shipping appears to be free (within Norway, I suppose), but that may depend on my interpretation of the word fraktfritt! (http://www.capris.no/customerservice.aspx) The first price shouldn't include any tax. I'm not certain what the situation is with tax on books in Norway, so I don't know if the price is inclusive of tax or not. I think it makes sense to look around for the best price, but I guess I don't understand the complaining about the price. I've got a copy of Stroustrup's C++ Programming Language that cost me $65 probably 5 years ago or more. I don't use it much, but the binding is falling apart, and it's not even a language I like. And considering what my daughter pays for college textbooks (actually what I pay for her books), Mark's book seems pretty reasonably priced - this isn't going to make the bestseller lists (no reflection on Mark - there just aren't that many PyQt users, although I've heard the plot is weak too), or even sell as many copies as the average college text. Considering we get free software that actually works and free, fast online support from the author of the software and the author of the book and the lead tech writer at TrollTech plus the other really knowledgeable people on this list, it doesn't seem to me that the price is that bad when you take all that into account. I can sympathize with people who have a hard time coming up that amount of money - I've been there. But then again, esp considering the Windows users who fork out a lot of money to Microsoft for software with less quality and support (even if it came 'free' with your computer) - I guess I don't think it's that bad to send less money than the price of Windows to Mark and someone willing to publish him. He can probably make better use of the money than Bill Gates. (I'd say less than Linux too, but I've been buying distros at CheapBytes, and most of you probably download). Divide the cost of the book by 4 for Qt, PyQt, Python and the book itself, and the price doesn't look too bad at all. Just my 2 cents - (and if I post enough of these you can cash them in and buy the book - but do it before the dollar falls even more). Now I have to go remove the cat from the microwave ... Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt book Rapid GUI Programming with Python and Qt now available
On Thursday 25 October 2007 18:20, David Boddie wrote: Note: As a reviewer, I received a copy free of charge, but I would have bought a copy anyway. I had to squeeze my reviewing duties in between work and real life, so I didn't really have the time to enjoy the book the first time around. :-) Heh - when I was teaching, I'd get a free copy and *paid* to review textbooks. Mostly on hardware, but one of my favorites was a text on BASIC for the PDP-11 (in the late 1980s - it was obvious PCs would dominate by then), with about half the book devoted to simulating logic gates in code. I was surprised the check cleared for that review. I'll probably pick up a copy just because there are some things in Qt4 I still haven't found time to get on top of, and some bad habits I should probably break. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] identify a QTreeWidgetItem
On Tuesday 23 October 2007 02:13, alteo_gange wrote:
Hi everybody!
I have created several QTreeWidgetItem and connected a signal
itemClicked(QTreeWidgetItem *,int) on the QTreeWidget.
treeWidget=QtGui.QTreeWidget(widget)
...
itemTree1=QtGui.QTreeWidgetItem(treeWidget)
...
itemTree2=QtGui.QTreeWidgetItem(treeWidget)
...
self.connect(treeWidget,QtCore.SIGNAL(itemClicked(QTreeWidgetItem
*,int)),self.function)
...
def function(self, item):
print item
'print item' return:
PyQt4.QtGui.QTreeWidgetItem object at 0x82cf62c.
It's very abstract!
I must identify QTreeWidgetItem in order to connect it an action (view a
widget on the right), but how? With a method of the item reference? Which?
I don't know.
Store the items in a dict as you create them:
self.itemDict = {}
itemTree1=QtGui.QTreeWidgetItem(treeWidget)
self.itemDict [itemTree1] = ?? # could be the associated widget that you want
# to connect to, or a
# string identifier
itemTree2=QtGui.QTreeWidgetItem(treeWidget)
self.itemDict [itemTree2] = ??
...
def function (self, item):
widget = self.itemDict [item]
...
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt4 snapshots don't build with -c -j
On Monday 15 October 2007 09:44, Andreas Pakulat wrote: Hi, yesterday I fetched a new PyQt4 snapshot and as always let it build with -c -j 8. After about 30 minutes that it spent on sipQtGuipart0 I stopped it and increased to -j 20. Same problem with that number. Even -j 30 causes this. I noticed though that the sipQtGuiPart0.cpp has only a difference of 100Kbytes between -j20 and -j30, that seems odd to me. Is there anything that can be done to fix this? (I've got a GB of RAM here, so that shouldn't be an issue) It really sucks having to disable concatenation as it speeds up compilation a lot. I always had such issues with PyKDE, but PyQt always worked fine using concatenation. What gcc version? Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] loading arbitrary kparts
On Monday 08 October 2007 07:41, Marcos Dione wrote: hi all. I've been playing with kparts a little and now I hit a wall. I try to load the proper part for a given url. the code I have looks like this: mime= KMimeType.findByURL(url, 0, False, False) mimeType= mime.name () # this trick I saw in # http://lxr.kde.org/source/KDE/kdegraphics/kuickshow/src/kuickshow.cpp?v=3.5 -branch#166 if mimeType=='application/octet-stream': mineType= KIO.NetAccess.mimetype (url, self); ptr= KTrader.self().query(mimeType, 'KParts/ReadOnlyPart' in ServiceTypes)[0] part= createReadOnlyPart (ptr.library (), tab, ptr.name ()) no matter what url it is, seems like I always get mimeType as application/octet-stream, and the part it loads it's an hex editor. I tried to find other examples of findByUrl(), but the only one that could be interesting (in konqueror) is very deep and can't wrap my head around it. I'm using KIO.NetAccess.mimeType in a PyKDE4 application and it works fine there - there could be some difference to the PyKDE 3 version. It would help if you'd provide a short example program that exhibits the problem so I can see if there's some other problem in the surrounding code triggering the mimetype problem. You could also try to use KRun, just as a *test* to see if it will pick up the mime type correctly (it launches an application though - doesn't load a part). I also found examples like this: mimetype == KMimeType::findByURL( m_url )-name(); m_part = KParts::ComponentFactory::createPartInstanceFromQueryKParts::ReadOnlyPart ( mimetype, QString::null, this, 0, this, 0 ); but I can't find the ComponentFactory namespace in pykde, and I'm not sure it would fix my problem. so, what am I missing? ComponentFactory consists of only templates, so there isn't any code to wrap, unless the templates are instantiated via a typedef somewhere else in kdelibs. KParts.Factory is implemented though. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] loading arbitrary kparts
On Monday 08 October 2007 16:16, Marcos Dione wrote:
Running this:
from kdecore import *
from kio import *
from kparts import *
import sys
KCmdLineArgs.init (sys.argv, sys.argv[0], testmime, , )
args= KCmdLineArgs.parsedArgs ()
app= KApplication ()
#app.exec_loop ()
for u in ('http://api.kde.org/3.5-api/kdelibs-apidocs/kde_gear_64.png',
'http://jbailey.livejournal.com/41057.html'):
url = KURL (u)
#mime = KMimeType.findByURL(url, 0, False, False)
#mimeType= mime.name ()
#if mimeType=='application/octet-stream':
#print trying harder
mimeType= KIO.NetAccess.mimetype (url, None)
print mimeType
I get:
[EMAIL PROTECTED]:~/Documents python testMime.py
image/png
text/html
Changing it to this:
for u in ('http://api.kde.org/3.5-api/kdelibs-apidocs/kde_gear_64.png',
'http://jbailey.livejournal.com/41057.html'):
url = KURL (u)
mime = KMimeType.findByURL(url, 0, False, False)
mimeType= mime.name ()
#if mimeType=='application/octet-stream':
#print trying harder
#mimeType= KIO.NetAccess.mimetype (url, None)
print mimeType
I get:
[EMAIL PROTECTED]:~/Documents python testMime.py
application/octet-stream
application/octet-stream
because (from the KDE API docs):
This function looks at mode_t first. If that does not help it looks at the
extension. This is fine for FTP, FILE, TAR and friends, but is not for HTTP
( cgi scripts! ). You should use KRun instead, but this function returns
immediately while KRun is async. If no extension matches, then
the file will be examined if the URL is a local file or
application/octet-stream is returned otherwise.
So PyKDE appears to be working correctly here. What version of PyKDE are you
using? Shouldn't make a difference, but if an older version you could try
upgrading.
You could also try to use KRun, just as a *test* to see if it will pick
up the mime type correctly (it launches an application though - doesn't
load a part).
will try.
but I can't find the ComponentFactory namespace in pykde, and I'm
not sure it would fix my problem. so, what am I missing?
ComponentFactory consists of only templates, so there isn't any code to
wrap, unless the templates are instantiated via a typedef somewhere else
in kdelibs. KParts.Factory is implemented though.
I didn't get this whole. can you explain a little more?
In C++, template types (classes or functions) only cause code to be generated
when they're used - in a typedef or when instantiated. If no code references
the template, then the template doesn't produce any code in the library or
application.
componentfactory.h doesn't contain anything except templates, and if nothing
else in the KParts module references those templates, they don't produce any
code.
PyKDE (PyQt/sip) works by providing an interface to code in .so libs. If no
binary code is there for a template type (and in this case there isn't any
code), there isn't anything to interface to, so it isn't possible to use
anything from componentfactory.h in PyKDE - there's no 'there' there.
Jim
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde crash on debian etch / import kparts or khtml
On Friday 28 September 2007 07:56, jbd wrote: I've got a small problem with an application i'm trying to port from sarge to etch. Here is the minimal application which mimics the problem. It's a simple QDialog with a QPushButton which triggers a KDirLister and print the result on stdout. It works well as long as i don't import khtml or kparts. I'm running a clean debian etch system : kdelibs : 4:3.5.5a.dfsg.1-8 python-kde3 : 3.15.2+20060422-3 python-qt3 : 3.16-1.2 The same code sample runs well on debian sarge but crash on debian etch and ubuntu feisty. It seems that's i'm doing something wrong here. It crashes here too (not on Debian). It appears to be related to the 'newItems' signal - that's where the backtrace indicates the crash is originating. I have no idea what the cause is, but I think you can achieve the same thing with the two changes below, and with those changes it works here. From looking at the comments in the KDE h files, it seems like there might be some kind of timing issues related to the signals, but I have no idea why importing other modules would trigger the problem. Jim # -*- coding: utf-8 -*- import sys from qt import QDialog, QPushButton, SIGNAL from kdecore import KCmdLineArgs, KApplication, KURL from kio import KDirLister # Remove one or both of the comment to crash the application #from khtml import * #from kparts import * # class TestCrash(QDialog): def __init__(self, parent=None): QDialog.__init__(self, parent) button = QPushButton(Run kdirlister, self) self._dirLister = KDirLister() self.connect(button, SIGNAL(clicked()), self._openHome) # self.connect(self._dirLister, SIGNAL(newItems(const # KFileItemList)), self.connect(self._dirLister, SIGNAL(completed ()), self._slotNewItems) self._slotNewItems) def _openHome(self): self._dirLister.openURL(KURL(/)) def _slotNewItems(self, items): print =*50 # for item in items: for item in self._dirLister.items (): print item.url().prettyURL() print =*50 def main(): try: KCmdLineArgs.init(sys.argv, crash test, crash test,crash test) app = KApplication(True, True) widget = TestCrash() widget.show() app.setMainWidget(widget) res = app.exec_loop() print Return value, res except Exception, what: print Exception catched:, str(what) sys.exit(-1) if __name__==__main__: main() ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] a CustomEvent in KTMLPart crashes eventFilter
One additional comment (that just occurred to me) - your version will work if you don't try to display a page (begin - write - end) before starting the event loop in KApplication. That's probably what's causing the crash. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 build error - int/Py_ssize_t conversions
On Tuesday 04 September 2007 04:42, Martin Böhm wrote: Hello list, there are some trouble with compiling the latest and greatest PyKDE4 (from KDE's on a 64bit machine, with Python 2.5.1. Namely it starts like this: sip/kdecore/kurl.sip: In function 'PyObject* slot_KUrl_List___getitem__(PyObject*, PyObject*)': sip/kdecore/kurl.sip:167: error: cannot convert 'int*' to It should now be fixed (I stole the update). It might take a few days to find its way into KDE SVN. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 build error - int/Py_ssize_t conversions
On Tuesday 04 September 2007 04:42, Martin Böhm wrote: Hello list, there are some trouble with compiling the latest and greatest PyKDE4 (from KDE's on a 64bit machine, with Python 2.5.1. Namely it starts like this: sip/kdecore/kurl.sip: In function 'PyObject* slot_KUrl_List___getitem__(PyObject*, PyObject*)': sip/kdecore/kurl.sip:167: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '3' to 'int PySlice_GetIndicesEx(PySliceObject*, Py_ssize_t, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*)' sip/kdecore/kurl.sip: In function 'int slot_KUrl_List___delitem__(PyObject*, PyObject*)': sip/kdecore/kurl.sip:135: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '3' to 'int PySlice_GetIndicesEx(PySliceObject*, Py_ssize_t, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*)' sip/kdecore/kurl.sip: In function 'int slot_KUrl_List___setitem__(PyObject*, PyObject*)': sip/kdecore/kurl.sip:93: error: cannot convert 'int*' to 'Py_ssize_t*' for argument '3' to 'int PySlice_GetIndicesEx(PySliceObject*, Py_ssize_t, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*, Py_ssize_t*)' Google search found out that this error was fixed in the past by replacing some int definitions into SIP_SSIZE_T. I've tried replacing them with ssize_t and it indeed continued compiling. Some more of similar errors are deeper down. Simon told me on IRC that it might be useful to post it here, which I am doing. I'll have to look at how Phil handled the typing for PyQt4/QStringList because that's where I stole the code from. Apparently I didn't steal quite enough. If you got that far, PyQt4 compiled correctly. It should show up in a couple of other places as well, unless KUrl::List is still older code and I copied newer code for the other instances. PS: Thanks to everyone for their work on (and with) pyqt and pykde! My pleasure. Thanks for the early bug report! Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Tuesday 04 September 2007 10:09, Andreas Pakulat wrote: On 04.09.07 09:35:34, Jim Bublitz wrote: Someone is interested in doing plugin code for Kate, and needs kdelibs/interfaces/ktexteditor and also kdesdk/kate/interfaces/kate. I'm not sure about that, KTextEditor already provides a plugin class and at least some plugins, like word completion, use that interface instead of the Kate::Plugin. Also the interfaces in kdesdk/kate/interfaces are not installed, so they might not be meant to stay (or somebody just forgot a CMakeLists.txt file), I'll ask the kwrite devs.. The kdesdk files provide the kate objects (application, documentManager, mainWindow, view). There's already a working application for KDE3 with its own set of bindings. There's another standard that relates to what's necessary to actually build the module?, which is why the kdeprint module gets complaints about having all kinds of things the developers want to be internal. If I chop out everything marked internal, there's not enough there to compile what's left, which is why all of those internal h files end up in the user's include directory in the first place. Well, kdeprint is pretty broken at the moment anyway. Its supposed to get basic fixing for the 4.0 release, but that mainly means making the most-used options useable again. I don't know if anyone's ever used it from PyKDE3, and I've never written any code against it - but it always compiles. In fact it's the least troublesome module in PyKDE. But for example, knewstuff installs dxsengine.h in users include/ directory. dxsengine.h depends on coreengine.h, which isn't installed. Not knowing anything about knewstuff, I don't know if I should a) drop dxsengine from the module or b) add coreengine.h (and associated sip file) to PyKDE or c) keep dxsengine but eliminate the dependency on coreengine (coreengine provides a base class - I can not tell sip about the base class and the dependency is solved, but all inherited methods are lost) or d) write some code manually to fix the problem (I can restore some or all of the inherited methods manually without coreengine or do other things). I can make any of those options work syntactically. Someone familiar with using knewstuff in applications should be able to provide or determine which is the correct choice. That someone probably isn't the developer, because (and I do this myself) developers have one view of how their classes should be applied, while users may come up with some cool new way to use something that the developer hadn't foreseen. Some of that is just part of how code evolves - the reason we don't all just stop at v1.0.0. But the initial decisions I make might leave the module totally unusable, or I might spend 10-15 hours wrestling with code to put in something there's no possible application for. I've done both, but I'd like to eliminate the first and minimize the second. And I'd like to be able to verify (with running code) that the choice was correct. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE and undefined symbols
On Tuesday 04 September 2007 15:16, Bart wrote: I've found some undefinied symbols in PyKDE-3.16 There are more errors like this one. Please check in your PyKDE module. How to solve this problem? Best regards. Bart. $ python Python 2.5.1 (r251:54863, Jul 31 2007, 09:34:25) [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 Type help, copyright, credits or license for more information. import kparts Traceback (most recent call last): File stdin, line 1, in module ImportError: /usr/lib/python2.5/site-packages/kparts.so: undefined symbol: _ZNK23konsoleBrowserExtension9classNameEv import kmdi Traceback (most recent call last): File stdin, line 1, in module ImportError: /usr/lib/python2.5/site-packages/kparts.so: undefined symbol: _ZNK23konsoleBrowserExtension9classNameEv jim:/home/jim # c++filt _ZNK23konsoleBrowserExtension9classNameEv konsoleBrowserExtension::className() const Run configure.py -x which disables konsolePart support (or alternatively edit the top level Makefile to remove konsole and konsolePart references. If the className() method isn't there, nothing related to konsolePart is. Not every Linux distribution supports (support varies by version too). configure.py should detect this automatically, and I thought it was off by default. You might be using an older version of PyKDE. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 09:48, Andreas Pakulat wrote: Just out of curiosity: Does PyKDE4 also work without GUI/X11 when one restricts himself to kdecore module? (I suspect so, but wanted to make sure) I was going to say probably, but KApplication is in kdeui now, so it seems less probable. The kdecore Makefile links in a bunch of X stuff, and kdecore also imports QtGui - I'm not sure at the moment if/why those are really necessary, but it wouldn't be hard to edit the Makefile and configure.py to find out. Thanks for the great work (also to Simon), I suspect I might get back to PyQt4/PyKDE4 hacking sooner, now that I've got the full KDE power at my hands :) Andreas PS: great work as in: having PyKDE4 ready for the 4.0 release, I didn't yet check it out, but the svn co is already running :) Thanks. JIm ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yeah - I don't know where they've gone. Are they in kdepim? They're no longer in kdelibs (or kdebase, or kdesdk). I don't download all of the source packages (I'm bandwidth limited). I'll be happy to take a look at them if they've moved. If they've moved, the only concern is if they've picked up new dependencies - otherwise putting them back isn't too much work. I think kmdi is just gone, but I haven't searched for that either. There is some MDI support in Qt4, but haven't looked at that much yet either. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:52, Andreas Pakulat wrote: On 03.09.07 21:08:15, Hans-Peter Jansen wrote: Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yes it is. There's some other things that might be cool to have in pykde4, like knewstuff, nepomuk and possibly threadweaver as well... It's not a problem to create more bindings - I ran through the 3 you mentioned and have sip files and could have compiling code with a few more hours work. However, there are a couple of problems with that that need to be addressed. The first is how large should PyKDE be? At some point I'd want to start splitting stuff off into a second package, and all 3 you mentioned would be good candidates for that. They're not really central to kdelibs for what I see as the average user. There are issues of release schedules, bug fixes, and general maintenance that increase more than linearly with the size of the code base. The second issue is why I'm going to insist on demo code. I can get sip to generate code for all three of those (already have) and with a few more hours work could get them to compile. But in the process of doing that, I have to make choices about things to leave in and leave out (the set of h files that installs is not sufficient, for example), as well as handwrite some code. I know nothing about threading or knewstuff, and last I heard, Nepomuk was a 14th century martyr and patron saint of Bohemia. I'll be happy to put together a tarball to play with with any or all three of those, but none is going into PyKDE or anything else I release until I'm confident that they work and users can figure out how to apply them. Learning threading or symantic desktops is not high on my list of priorities, but I'll get to it eventually (a year or two). Someone can speed that up by volunteering to debug bindings for those packages AND producing test code/examples or (at best) a tutorial. Docs I can get for free from the h files. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? From the comments downthread, would you want kabc or akonadi? Do they need to part of PyKDE, or can they be in a separate package (along with other add-ons)? Can you write some example code for kabc? I'm still skeptical about the PyKDE3 version, as there was some class or global variable or something I had to omit from the bindings. I'd like to know these are usable before releasing them. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Crash in KMainWindow.saveProperties() [small sample C++/Python code provided]
On Tuesday 28 August 2007 11:10, Adeodato Simó wrote: Hello. I'm getting the same backtrace as mentioned in [1]. Please find attached a minimal C++ example application that successfully saves its state, and a Python equivalent that crashes when logging out of KDE. Note that the crash is not related to using config, just providing an empty saveProperties() crahses as well. It doesn't crash here (just running the simple app you attached), so I can't actually test a solution, but Simon Edwards ran into a similar problem with PyKDE4 and fixed it by globally declaring 'application' (from your example): application = None and then inside main(), adding: global application I think that should ensure that KApplication is the last object destroyed. The other possibility is to construct the main window and KApplication in global space, after the if __name__ == __main__ test, instead of putting them inside a function or class method. That seems to have fewer problems with exit crashes (but other things can cause them as well). As has been noted, the crash probably has to do with the order in which objects are destroyed. PyKDE at one time tried to addressed this (probably with code stolen from PyQt) - it gets to be a problem as KDE/Qt change and possibly even as gcc/g++ changes it's exit code for C++. It also can cause problems with queryClose/queryExit methods in KApplication, and with session management. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Presenting Minirok, a 2.5k lines app in PyKDE (and thanks!)
On Saturday 25 August 2007 10:45, Adeodato Simó wrote: Hello there. Since it doesn't seem to exist a whole lot of free software applications written in PyKDE (at least I only count 4 in Debian/Ubuntu), I thought I'd drop a line to say that there's one more now. But first, I would really like to thank the PyKDE authors for providing such a comprehensive and high quality set of bindings. Despite my first troubles with them [1, 2], I'm very happy I did stick to them, since they've enabled me to achieve my objective with little annoyance. Keep up the good work, and hopefully the bindings for KDE 4 will be complete enough! [1] http://www.riverbankcomputing.com/pipermail/pyqt/2007-August/016865.html [2] http://www.riverbankcomputing.com/pipermail/pyqt/2007-August/016869.html Now for the application, Minirok, it's a small music player which I wrote to replace Amarok, partly because I was becoming unhappy with it, partly because I wanted some Python project to work on. The look and feel it's mostly the same as Amarok's. http://chistera.yi.org/~adeodato/code/minirok/ Thanks for the nice words, especially after I haven't been too helpful in fixing remaining PyKDE bugs. I am spending a lot of time on PyKDE4 (for KDE4), and one of the things I'm doing is trying to both test and develop working examples for as many of the classes as I can before the official release sometime in October. I do appreciate your earlier bug reports, and will try to make sure those are fixed in the initial release. Thanks again, Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] can't create a QPainter in QTreeWidget's paintEvent
On Wednesday 22 August 2007 13:49, Devon wrote: Hi, folks - Here is a dummy version of a derived tree widget: class MyTreeWidget(QTreeWidget): def __init__(self, parent=None): QTreeWidget.__init__(self, parent) def paintEvent(self, e): QTreeWidget.paintEvent(self, e) painter = QPainter(self) painter.end() When an instance is added to a layout, I get the following: QPainter::begin: Widget painting can only begin as a result of a paintEvent QPainter::end: Painter not active, aborted Any ideas what is causing the the painter to think it's not actually in a paintEvent? I'm using Qt 4.3.1, PyQt 4.3 and SIP 4.7 The first thing to look at is whether e is a paint event or not: if e.type () == QEvent.Paint: print Paint Event else: print not Paint Event, e.type () The values for e.type () are on the QEvent page in the Qt docs. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] problem with abstract classes
On Sunday 12 August 2007 07:20, Diez B. Roggisch wrote:
Hi,
I'm in the process of wrapping the irrlicht 3d engine. So far, things
have been working smoothly. However, now I stumbled over a problem that
so far has not been willing to be disappearing, intensive gdb-use
notwithstanding.
There is a pure abstract class in Irrlicht, IEventReceiver. It looks
like this:
//! Interface of an object which can receive events.
class IEventReceiver
{
public:
virtual ~IEventReceiver() {};
//! called if an event happened. returns true if event was processed
virtual bool OnEvent(SEvent event) = 0;
};
This class I wrapped in SIP this way:
class IEventReceiver /Abstract/ {
%TypeHeaderCode
#include IEventReceiver.h
%End
public:
bool OnEvent(irr::SEvent event);
};
The line for the method OnEvent should be the same in the sip file as in the h
file - sip needs to see the = 0, and it makes no sense to add that unless
the method is marked 'virtual'.
I'm not sure I follow the rest of the explanation (likely my fault), but my
guess is that sip is generating code to call a method that isn't there (a
pure virtual) - you haven't told sip the method doesn't (concretely) exist.
Jim
Which seems to work fine. Now of course I'm having troubles subclassing
this class in Python, which is the reason I created a dummy-implemntation
namespace irr {
class PyIEventReceiver : public IEventReceiver {
public:
virtual ~PyIEventReceiver();
bool OnEvent(SEvent event);
};
};
It is declared in my SIP-file as this:
class PyIEventReceiver : irr::IEventReceiver {
public:
bool OnEvent(irr::SEvent event);
};
I can subclass this class in python, and my SEvent-marshalling-code
works fine as well, as the following test-script shows:
class MyER(irrlicht.irr.PyIEventReceiver):
def OnEvent(self, event):
print event
er = MyER()
event = (irrlicht.irr.EET_MOUSE_INPUT_EVENT, 100, 100, .5, 1)
er.OnEvent(event)
But now if I set this IEventReceiver to my IrrlichtDevice, I get the
following error (inside GDB):
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0008
0x0297119f in irr::CIrrDeviceStub::postEventFromUser (this=0x141a8f0,
event={EventType = EET_MOUSE_INPUT_EVENT, {GUIEvent = {Caller = 0x145,
EventType = 247}, MouseInput = {X = 325, Y = 247, Wheel = 0, Event =
EMIE_MOUSE_MOVED}, KeyInput = {Char = 325, Key = KEY_CRSEL, PressedDown
= false, Shift = false, Control = false}, LogEvent = {Text = 0x145
Address 0x145 out of bounds, Level = 247}, UserEvent = {UserData1 =
325, UserData2 = 247, UserData3 = 0}}}) at
/Users/deets/Download/irrlicht-1.3.1/source/Irrlicht/MacOSX/../CIrrDeviceSt
ub.cpp:164 164 absorbed = UserReceiver-OnEvent(event);
(gdb) p UserReceiver
warning: RTTI symbol not found for class 'irr::NSOpenGLViewDeviceDelegate'
$1 = (IEventReceiver *) 0x1492ec0
Current language: auto; currently c++
UserReceiver here is a pointer to a IEventReceiver, which seems to be
correctly set. I tried stepping into the code, but wasn't able to.
This is with OSX 10.4, Python2.5, latest stable sip (4.7).
Any suggestions? Am I doing something fundamentally wrong wrt
implementation of C++-interfaces?
Kind regards,
Diez
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Multiple inheritance involving KXMLGUIClient does not work?
On Saturday 11 August 2007 11:48, Adeodato Simó wrote: Hello. I'm having problems with KXMLGUIClient; in particular, it seems subclassing from it does not work when multiple inheritance is involved. See the script below. If this gets fixed, the attached example should work as well. (I seem to be pushing PyKDE to its limits, and I've already found three non-working features which I need for my application. As I've said before, I understand that you're not very inclined to fix them for KDE 3, but what are the odds that they'll work in KDE 4? I guess my application can live without them until then, but I'd like to know if the future will indeed be better. I'm afraid all I can provide is working/non-working C++/Python examples.) sip doesn't support multiple inheritance in Python classes . It does support C++ classes which have multiple base classes, so you could create your own C++ classes that inherit from KXMLGuiClient and QObject and wrap them. It won't work in PyKDE4 either. It won't change unless Phil modifies sip, and I suspect there are good reasons why that isn't going to happen, but can't speak for Phil. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4 progress report
As of a few minutes ago, I have a working PyKDE4 version for KDE 4 beta 1 (3.92.0). Working in the sense that all the modules will load and I can run a simple app that puts up a window. If anyone is interested in playing with it (it's still very rough) drop me an email directly ([EMAIL PROTECTED] - put PyKDE in the title so I don't think it's spam), and indicate either a) which classes you're going to write example programs for or b) which classes you're going to write test code for. Absent either (a) or (b), requests are likely to be ignored. If you're not sure, I'll be happy to suggest something. Future requests for pre-release tarballs, features, or assistance will depend on whether I've received promised example or test code. Sorry to be a hardass, but one of the biggest problems with PyKDE3 was that it had insufficient example code and even less test code so that even as of a few days ago people are still discovering significant parts of PyKDE3 that just don't work. I hope to avoid that situation in the future. I plan to do considerably more of that kind of thing, but with something like 600 classes and 10,000 methods and over 1 million lines of C++ code - those are PyKDE3's stats - it's difficult to cover even the high spots, especially given the fact that I don't know what a lot of PyKDE even does. Simon Edwards (whose still on holiday, I think) will eventually be incorporating PyKDE4 into the KDE SVN (under kdebindings), so it should be available in some form in one of the later betas or early release candidates. This won't be available for download otherwise until the initial official release (except as noted above), after which I'll provide tarballs as in the past. Well ... hopefully in a more timely fashion than in the past. At any rate, if things work according to plan, Simon will be able to issue new releases with new KDE versions as well. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] KGlobalAccel, again
On Friday 03 August 2007 11:50, Adeodato Simó wrote: Hello. I'm having the same problem as [1] when using KGlobalAccel. In a nutshell, the program crashes when pressing the configured global shortcut. [1] http://www.riverbankcomputing.com/pipermail/pyqt/2006-May/013268.html I tried adding /Transfer/ to the KGlobalAccel constructor as suggested there, but the result is the same (patched the PyKDE version in Debian, 3.15.2+20060422; 3.16.0 gave me a compiler error when building). I would really really really like to see this fixed. If there's anything I can do to help with that, please let me know. Here's a sample program that shows the issue: run it and press Ctrl-Alt-U. The /Transfer/ in KGlobalAccel should be /TransferThis/, but that makes no difference in your example program, which as far as I can see is correct. The backtrace shows calls to createPopupMenu just before the crash, and as far as I can tell from looking at the C++ code, that shouldn't be called. From Python's point of view, if you interrogate the KGlobalAccel object, or the KAccelAction object insert() returns, everything is set up correctly. It could be a bug in the C++ KDE code, although I'd be surprised (a C++ test case would be helpful). It could also be some misunderstanding of how to use KGlobalAccel, but that seems unlikely too. It's probably a PyKDE problem, but it's one I'd find very difficult to track down and what time I have to spend on PyKDE is going to the upcoming KDE4 version. With that only a few months away, I'm reluctant to spend a lot of time on PyKDE3, and this looks like it would take a lot of time - I've spent a few hours on and off on it today If I get some free time, I'll try to get back to it, but that's not likely at the moment - sorry. Anyone else is welcome to look into it. Jim. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyKDE] KHTML method returning null
On Monday 05 March 2007 08:29, Paul Giannaros wrote: The documentation for KHTML's DOM::Document::getElementById ( http://api.kde.org/3.5-api/kdelibs-apidocs/khtml/html/classDOM_1_1Document. html#a20 ) show's that the method returns null when an element in the webpage by the given ID hasn't been found. I would have thought that would have mapped to Python's None, but instead I'm getting a khtml.DOM.Element. If the underlying C++ call returns null, the PyKDE call should return None (see sip_api_return_from_new_instance in siplib/siplib.c) Whenever I try to call a method on it, my application crashes with terminate called after throwing an instance of 'DOM::DOMException'. Firstly, is this intended behaviour? I don't think so. Secondly, is there any way that I can check if the return value from that call is a valid object? Try accessing some method of the object, I suppose (you can also check its Python type, of course, but that only tells you what Python thinks the object is). I'd suggest posting a short example program that demonstrates the problem (include the html necessary to cause it too). Most of this stuff is straightforward sip wrappers - meaning sip generates the code the same as for any other C++ class, and there isn't anything unusual or customized that I can see. That suggests the most likely problem is in the implementation you're doing - the commonest problem is not keeping a Python reference to an object you're trying to access, for example. However the khtml, and especially DOM, stuff hasn't gotten a lot of use, and I have no application code to test it with, so problems either in PyKDE or the underlying KDE code are quite possible too. Either way, an example would be useful to see what's happening. Jim Maybe there is something you can do with the sip module? (though I can't see anything in the docs) Thanks, Paul ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Speeing up source file creation when using SIP with PyQt/PyKDE
On Tuesday 20 February 2007 06:28, Paul Giannaros wrote: I'm creating bindings for a module in KDE (not included in PyKDE). While things work fine, running sip on the .sip file takes a long time on my machine -- ~15 seconds. It looks like it's processing all of the Qt/KDE sip stuff each time. I don't fully understand the sip system, but is there a way I can stop it doing so, and just process my single one? None of the arguments to `sip` look promising, neither does a quick search of the documentation help. You're right - it is processing all of the Qt and KDE stuff that you import. For example, if you have classes (which you almost certainly do) that subclass QObject or QWidget, their header/sip files contain only the information about the methods that the class's new methods or the inherited methods that it overloads. However, when you use the new class, you expect to be able to access any method inherited from QObject or QWidget, so sip has to generate bindings (within the new class) for all of those methods as well, and to do that, it needs to know what those methods are - exactly the same as gcc/g++ needing to see qobject.h, etc. Jim ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
