Language Bindings

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.

You tryed to use listView->clean(); ?

Moved to the language bindings forum..

I must say that I’m sorry for no new releases since last beta. But since then we have actually had quite active development, so we’ll near (hopefully) final beta this year and RC at start of next year.

You can see activity log here: http://qt.gitorious.org/qt-jambi

Not exactly empty, isn’t it? :)

I’ve been working for new website to collect all Jambi related information under same hood. This should be released soon too.

4.8 basically already compiles, but new features aren’t still polished. With current development rate it should arrive shortly after 4.7 release, atleast I hope we can make it so :)

Sorry, I have no idea how matlab creates its libraries; I'm out here. Maybe someone in a matlab forum can be of better help, as it doesn't seem to be a Qt problem, but more one of interfacing matlab libs with C++ code.

Found the solution!
The script isn't generating a image file properly because It doesn't has a QImage.fill(). Upon declaring one, the script generates the image correctly.
The following script (a modified version of the first script I posted) does what I needed:

@
#!/usr/bin/python

import sys
from PySide.QtCore import *
from PySide.QtGui import *

app = QApplication(sys.argv)

size = QSize(100,100)
picture = QImage(size, QImage.Format_RGB32)
picture.fill(32)
picture.setAlphaChannel(picture)

painter = QPainter()
painter.begin(picture)
painter.setRenderHint(QPainter.Antialiasing)
painter.setBackgroundMode(Qt.TransparentMode)
pen = QPen()
color = QColor(255,0,0)
pen.setColor(color)
pen.setWidth(5)
pen.setCapStyle(Qt.RoundCap)
painter.setPen(pen)
painter.drawEllipse(10,10, 80,80)
painter.end()

imagefile = QImageWriter()
imagefile.setFileName("circle")
imagefile.setFormat("png")
imagefile.setQuality(100)
imagefile.write(picture)

exit()

app.exec_()
sys.exit()
@

Nevermind, I found the bug in the above code and edited it so it now works.

But the code would better be:
@def itemChange(self, change, value):
print "itemChange", change, value
return value@

The critical part of the documentation is "The default implementation does nothing, and returns value." More precisely it could say: simply returns the passed parameter having name value, unchanged.

There is no reason to call the base class implementation, but you MUST return a result having the same type as the parameter named value.

That is, itemChange() is a hook: it is called when Qt has a value for a change and gives you the opportunity to alter the value before Qt uses the value. If you don't return a value properly, the results are unpredictable. The default implementation is an idempotent hook: transmits the value parameter unchanged.

Note that itemChange(), like sceneEvent() and a few other methods in the list of protected methods of QGraphicsItem have non-void return value. Be careful to return a value that is not None. Apparently Qt does not do run-time error checking (or at least in the Python binding, a returned value of None passes any type checking that Qt does.)

The documentation for itemChange() says "adjustments can be made." This is poor technical writing because it uses the passive voice. It would be better stated: in your reimplementation, you can adjust the value, but you should always return a result having the same type as the parameter named value.

The code and documentation would also be better if longer names were used: itemChange(changeType, changeValue). As you can see in my discussion above, it is difficult for readers to distinguish between the parameter having name value, and the value of that parameter. In other words, the word "value" is too abstract and generic. "Return a value" is too easily confused with "return the parameter having name: value".