| Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi! I use Qt for the user interface in my project and Jython to get some scripting support. Jython automatically discovers all Java classes and interfaces the Java classloader knows about and makes them available to python scripts. So that way the scripts get access to the full application as well as all of Qt Jambi, which goes a long way towards fully scriptable UI elements. But there is a catch: Qt's signal/slot mechanism. Jambi resolves slots by using reflection on the target objects as far as I can tell without looking at the source. But if the target object is created from a Jython class any methods that are not implementations of Java interfaces or overwritten superclass methods will not be visible through Java reflection (Jython has its own way of managing that information, though). So it is not possible to implement slots purely in Python because Jambi won't be able to find them. Is it possible to extend Jambi's signal/slot mechanism so that it does not only try to do Java reflection but also Jython/Python reflection if possible? Regards, Gregor -- [ signature omitted ]
Attachment:
pgp5gEqwjmwpn.pgp
Description: PGP signature
Gregor Mückl wrote: > Hi! > > I use Qt for the user interface in my project and Jython to get some scripting > support. Jython automatically discovers all Java classes and interfaces the > Java classloader knows about and makes them available to python scripts. So > that way the scripts get access to the full application as well as all of Qt > Jambi, which goes a long way towards fully scriptable UI elements. But there > is a catch: Qt's signal/slot mechanism. > > Jambi resolves slots by using reflection on the target objects as far as I can > tell without looking at the source. But if the target object is created from > a Jython class any methods that are not implementations of Java interfaces or > overwritten superclass methods will not be visible through Java reflection > (Jython has its own way of managing that information, though). So it is not > possible to implement slots purely in Python because Jambi won't be able to > find them. > > Is it possible to extend Jambi's signal/slot mechanism so that it does not > only try to do Java reflection but also Jython/Python reflection if possible? Hi Gregor, I've actually been quite curious about this myself, and tried did some python scripting with Jambi some time back. I found the same limitation you found and didn't look more at it, but since this came up I decided to hack something together. Its very crude (30 mins work) at this point, as I didn't use the jython Java API before, but it illustrates how I would conceptually solve the problem... Instead of hooking into the Signal.connect() function directly I would create a new function in the global namespace and let it be implemented as a java function that handles a Jambi connection and then calls back into jython whenever it gets triggered. I implemented the 0 arguments version but it should be easily extendable to more arguments with, pluss I'd add some safty checks here and there ;-) I hope this gives some insight ;-) - Gunnar
package com.trolltech.tests;
package com.trolltech.tests;
import com.trolltech.qt.*;
import com.trolltech.qt.gui.*;
import org.python.core.*;
import org.python.util.*;
class PythonSlot0 {
public void execute() {
receiver.invoke(functionName);
}
PyObject receiver;
String functionName;
}
class ConnectFunction extends PyObject {
@Override
public PyObject __call__(PyObject[] pyObjects, String[] strings) {
QSignalEmitter.AbstractSignal signal =
(QSignalEmitter.AbstractSignal) pyObjects[0].__tojava__(QSignalEmitter.AbstractSignal.class);
PyObject receiver = pyObjects[1];
String function = pyObjects[2].toString();
if (signal instanceof QSignalEmitter.Signal0) {
PythonSlot0 slot = new PythonSlot0();
slot.receiver = receiver;
slot.functionName = function;
signal.connect(slot, "execute()");
}
return null;
}
}
public class Python {
public static void main(String args[]) {
QApplication.initialize(args);
PythonInterpreter ip = new PythonInterpreter();
ConnectFunction connect = new ConnectFunction();
ip.set("connect", new ConnectFunction());
if (args.length != 1) {
System.err.println("input script name, please...");
return;
}
ip.execfile(args[0]);
QApplication.exec();
}
}
from com.trolltech.qt.gui import *
from com.trolltech.qt.gui import *
import sys
class MyWidget(QWidget):
def paintEvent(self, event):
brush = QBrush(QLinearGradient(0, 0, self.width(), self.height()))
p = QPainter()
p.begin(self)
p.fillRect(0, 0, self.width(), self.height(), brush)
p.drawLine(0, 0, self.width(), self.height())
p.end()
def foobar(self):
print('hallo')
w = MyWidget();
b = QPushButton();
b.show();
b.setCheckable(1)
b.toggled.connect(w, "setVisible(boolean)");
connect(b.pressed, w, "foobar");
On Monday 19 March 2007, Gunnar Sletta wrote: > Gregor Mückl wrote: > > Hi! > > > > I use Qt for the user interface in my project and Jython to get some > > scripting support. Jython automatically discovers all Java classes and > > interfaces the Java classloader knows about and makes them available to > > python scripts. So that way the scripts get access to the full > > application as well as all of Qt Jambi, which goes a long way towards > > fully scriptable UI elements. But there is a catch: Qt's signal/slot > > mechanism. > > > > Jambi resolves slots by using reflection on the target objects as far as > > I can tell without looking at the source. But if the target object is > > created from a Jython class any methods that are not implementations of > > Java interfaces or overwritten superclass methods will not be visible > > through Java reflection (Jython has its own way of managing that > > information, though). So it is not possible to implement slots purely in > > Python because Jambi won't be able to find them. > > > > Is it possible to extend Jambi's signal/slot mechanism so that it does > > not only try to do Java reflection but also Jython/Python reflection if > > possible? > > Hi Gregor, > > I've actually been quite curious about this myself, and tried did some > python scripting with Jambi some time back. I found the same limitation > you found and didn't look more at it, but since this came up I decided > to hack something together. Its very crude (30 mins work) at this point, > as I didn't use the jython Java API before, but it illustrates how I > would conceptually solve the problem... > > Instead of hooking into the Signal.connect() function directly I would > create a new function in the global namespace and let it be implemented > as a java function that handles a Jambi connection and then calls back > into jython whenever it gets triggered. I implemented the 0 arguments > version but it should be easily extendable to more arguments with, pluss > I'd add some safty checks here and there ;-) > > I hope this gives some insight ;-) > > - > Gunnar Hi Gunnar, Wow! This code looks great. Thank you very much! I must freely admit that I could not come up with a fix like this. I think I can make that work. This would make a good article for Jython monthly, too, I think. Gregor PS: Carthage should be ... sorry, I mean, do you have a vague timeframe in which we can expect the final release or a release under an open source license? -- [ signature omitted ]
Attachment:
pgpRQB3Q49hzw.pgp
Description: PGP signature
Gregor Mückl wrote: > Hi Gunnar, > > Wow! This code looks great. Thank you very much! I must freely admit that I > could not come up with a fix like this. I think I can make that work. This > would make a good article for Jython monthly, too, I think. hm... intriguing... Are you volunteering for an article? ;-) > PS: Carthage should be ... sorry, I mean, do you have a vague timeframe in > which we can expect the final release or a release under an open source > license? I really don't want to say too much, but I hope we'll get the licensing sorted out for the next beta in April / May. If it takes more time it'll have to wait for the final release which is scheduled for this summer. - Gunnar
Gunnar Sletta wrote: > Gregor Mückl wrote: > >> Wow! This code looks great. Thank you very much! I must freely admit that >> I could not come up with a fix like this. I think I can make that work. >> This would make a good article for Jython monthly, too, I think. > > hm... intriguing... > Are you volunteering for an article? ;-) Are you volunteering him for a Qt Quarterly article? ;-) David -- [ signature omitted ]
On Monday 19 March 2007, David Boddie wrote: > Gunnar Sletta wrote: > > Gregor Mückl wrote: > >> Wow! This code looks great. Thank you very much! I must freely admit > >> that I could not come up with a fix like this. I think I can make that > >> work. This would make a good article for Jython monthly, too, I think. > > > > hm... intriguing... > > Are you volunteering for an article? ;-) > > Are you volunteering him for a Qt Quarterly article? ;-) > > David Hi! Sorry for the late answer to this. I would write an article on this, but I won't be able to find enough time to do it for at least another month or so, unfortunately. I don't know if this would still be of interest by then. Gregor -- [ signature omitted ]
Attachment:
pgptiKuAYsr98.pgp
Description: PGP signature
Gregor Mückl wrote: > Hi! > > Sorry for the late answer to this. I would write an article on this, but I > won't be able to find enough time to do it for at least another month or so, > unfortunately. I don't know if this would still be of interest by then. Hi Gregor, I'll probably post some more on this when I refine it, so we can look more at it then maybe ;-) - Gunnar