Language Bindings

By changing line 7: @class Test:@ to @class Test(object):@ it's not running into segfaults anymore on my system. Using old-style classes (not using the ultimate 'object' base class) in Python is being discouraged for quite some time now and this makes me think PySide can't handle them, or this is just a bug.

@Smar: okay good :) I haven't tried QtJambi yet but lately my interest into a Java-Qt binding has increased much so I tried to find out about progress but finding up2date information was pretty hard. Imho blogging more often would help to some part - especially about the "roadmap" maybe a post about "how to help" would also be good (simple junior tasks?) Are there any plans for Qt5 yet? What about the whole QtScript/V8 stuff? Maybe a "live ticker" of commits somewhere visible on the homepage to help show the project is alive. [edit:] and no the "Recent activity" link doesn't help that much because on gitorious the first repository visible is shown as unmaintained and if you scroll down to the list of recent activity there are 90% of activity of repo creation/deletion - which doesn't show coding progress :( So a commit tracker of qtjambi-community (that's the current head isn't it?) may be the right thing.

This one. @self.findPrevious.emit(text, cs)@ But, I think signal can not emit multi-arguments in PySide. However, C++ can it. @emit findPrevious(text, cs);@

Yes, I've completely forgotten about writing it here. This is indeed the solution. The comments in the buildpath.properties kinda confused me, I thought setting the QTDIR variable would configure everything but that was not the case. Thanks for writing the solution here.

Yes, as signal is member of class instead of instance.

Apologies, suddenly it occurred to me, so in case someone else is wondering too: self keeps the scope of the object alive for example if a child widget is created in a parent method, the child will be garbage collected by python if self is not passed to it (making the object a child of the parent widget) or a reference is kept on the parent object i.e. @ example 1 def create_tray_icon(self): # without self the tray object is deleted on exit of this method # but passing self makes the parent widget own the child object tray = QtGui.QSystemTrayIcon(QtGui.QIcon(":/icon.png"), self) @ @ example 2 def create_tray_icon(self): # we don't pass self but the parent has a reference to tray (self.tray) # so the tray object will not be deleted until the parent is. self.tray = QtGui.QSystemTrayIcon(QtGui.QIcon(":/icon.png")) @

bq. for scalability reasons, the Q*Widget should only be used for static content you mean in this case using QTableWidget will be too slow for large tables as opposed to sub classing QTableView and building the required stuff yourself? Someone pointed out the QTableWidget.setCellWidget method which lets you do what I'm after very easily, but according to what you are suggesting this will become a problem? I'm just really trying to learn things the right way if possible so please excuse my ignorant questions bq. You are in charge of creating the corresponding widget for the cell. This is the QStyledItemDelegate::createEditor role. thanks, I will investigate that more.

I have no clue how would you map things, but from my standpoint, it doesn't seem possible. Templates here are used for things that java generics can't do... heck, not even all C++ compilers can process the code :) The library is at http://gitorious.org/qt-functional Not sure how many more improvements it will receive in the next period. Hoping I'll have the times to work on it again in a few months.

For future reference, I have come up with a solution to the problem. See here http://stackoverflow.com/questions/9490453/ctrlalt-key-modifier-behavior-with-qt-on-windows-when-a-textbox-has-focus

After digging around more I suspect I need to set centralwidget to the new window object to keep everything in the same main window context. Advice still welcome ;-)

Port blocking rules on your router do not apply on your local network and DB Manager automatically opens the configured port on your computer.

This really isn't medium to be posting the program, please create and account and attach to the bug tracker http://redmine.smar.fi/projects/qtjambi/issues (even through we are not sure if it really is a bug or what at this stage). You are comparing Win32 against Linux 64bit, so the -1 issue maybe related to that. Yes it is known that the C++ ModelIndex is more flexiable for C++ because it follows the language features. There are some obvious patterns on how to do things in Java that QtJambi does not support because those patterns are not how things get done in C++. Code like this is bad "new TestListToTreeProxyModel().show();". If you intended the life-time of the object to exist across the call the QApplication.exec() then you should assign it to a local varable. A memory restricted JVM (such as those used in embedded situations) is perfectly entitled to destroy your object before calling exec() which defeats the purpose of your application. This only works due to a quirk of the implementation of how Desktop Java works but the program as-is is not correct.

I think that additional language bindings for Qt for other languages is always worthwhile. However on the other points I think your view of the world is somewhat different to my own. "C++ is not a modern language." -- but still remains practical, efficient, maintained, understood at solving computer problems in 2012. "Jambi is more an alternative to the not so much used SWT." -- SWT is far more used than QtJambi is, the major driving force behind that is IBM and Eclipse. Even as a Qt supporter; I don't think it is fair to say SWT is not so much used, I think some publishers have claimed the Eclipse ecosystem is worth over a Billion dollars back in '06. [Source: InfoWorld.com 18-Sep-2006, IT Jobs Report, page 22, article: Eclipse: A Billion-Dollar Baby?] "Because every Jambi developer needed to put to its platform independent Java-binaries (mostly *.jar files) platform dependent DLL’s or so’s. But the most Java-developer prefered to create 100% platform independent Java-programs. And so they used Swing." I think you misunderstand the two points here, they are not related. Point 1) Are you aware that each Java Runtime Environment includes a bunch of platform dependant DLLs or DSOs. Also that Swing and AWT itself is implemented via the use of those DLLs/DSOs. Just because they are hidden to you (because you did not take the time to look) does not mean they do not exist. In this regard QtJambi is no different, but I can understand your point, a developer wishing to use QtJambi must think about how to bundle platform dependant JARs so their application deploys correctly. However changes are being made reduce the amount of work needed to deploy an application, there are technologies like OSGi and Jigsaw (either already here or on their way) that will do all the heavy lifting with regards to managing the platform specific part. Point 2) The platform indepedancy claim is really being honoured at the API level presented to the application programmer. Would you believe it but the Qt C++ API also attempts to achieve this across the wide range of devices it has been targeted for. There is no need when using QtJambi for an application programmer to understand any C++, use any C++, they can do all their working in Java using their favorite development environment with a high degree of confidence that if they wanted their application to work on one of the other major desktop platforms (windows/linux/mac) they only need to switch 2 JAR files in their project. ... While I do not know enough about the language D to comment on that matter, I can confirm my own findings with Qt C++ application compared with Qt Java application development. I think Java assisted by its incredibly good tooling is a faster application development environment (than C++). I think that building and maintaining large (many committers, many LoC, many independant teams working on modules) reliable projects in Java is far easier (than C++). I think that it is too easy for bugs in C++ applications to cause unrecoverable crashing with 1 bug bringing the while application down. While I appreciate a better job of building (faster, memory efficient) an application is possible in C++ this does not come without a cost, many classes of application exists where the efficiency difference is just not that important. [I remember a talk I heard when QML was being explained that when Qt devs tested they found JavaScript to not be that much slower; I cracked out my wry smile] We're living in a world where a mobile handset device has ~1Gb memory and quad-channel memory exists on the performance desktop (and will soon be in that mobile handset). Many of my points are not really caused by Java (the language) itself but by the use of a VM. I look forward to other VMs and languages on VMs becoming mainstream in the future; but for now JVM will do for me. Maybe some of these points translate well to the language D.