| Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hello, and thanks for a great framework now supported via Java. You are seeking feedback, and here's a couple: 1) I see no way to mix JComponents and Jambi classes. It seems that if you want to use Jambi, you will have to stick to that throughout your GUI app, stating with QApplication/QMainWindow. It's a pity for us experienced Swing users that already have a lot of homegrown component we want to mix with Jambi (best of all breeds...) 2) I hope you are working with a Designer plugin for IntelliJ as well, which is favourite IDE for a lot of Java developers. As a first step for supporting IntelliJ, I would suggest that you could make a JavaDoc version of the class documentation if that's possible so that one could have quick help on classes/method with Cntrl-Q. This REALLY is a must for quick programming practices. Best regards, Helge Fredriksen
On Wednesday 2 August 2006 08:35, Helge Fredriksen wrote: > 1) I see no way to mix JComponents and Jambi classes. It seems that if > you want to use Jambi, you will have to stick to that throughout your > GUI app, stating with QApplication/QMainWindow. It's a pity for us > experienced Swing users that already have a lot of homegrown component > we want to mix with Jambi (best of all breeds...) Hi, I'm no Qt expert, but I can answer the above. To mix Qt and Swing widgets gives you about the same problems as mixing AWT and Swing widgets. Except for the ugliness factor that people associate with awt :) So, if you search for "mixing lightweight and heavyweight" you'll find a list of all the annoyances. What I think would be a better road to walk down is a project that wraps the Graphics2D interface around QPainter so you can just paint your swing widgets onto a QWidget. With a cool glue class you might get that working :) Just an idea... -- [ signature omitted ]
Attachment:
pgpO5ng5PZYgQ.pgp
Description: PGP signature
Thomas Zander wrote: > I'm no Qt expert, but I can answer the above. > To mix Qt and Swing widgets gives you about the same problems as mixing > AWT and Swing widgets. Except for the ugliness factor that people > associate with awt :) Not completly true... At least putting Swing widgets into a AWT gui is a no-op since JComponent inherit Component and fit nicely into any layout manager. > So, if you search for "mixing lightweight and heavyweight" you'll find a > list of all the annoyances. I'm sure of it ;-) > What I think would be a better road to walk down is a project that wraps > the Graphics2D interface around QPainter so you can just paint your swing > widgets onto a QWidget. With a cool glue class you might get that > working :) We have thought about it. We'll decide to do or not based on the amount of feedback. This kind of thing would even be quite fun to do ;-) - Gunnar
Helge Fredriksen wrote: Hi Helge, and thanks for the feedback ;-) > 1) I see no way to mix JComponents and Jambi classes. It seems that if > you want to use Jambi, you will have to stick to that throughout your > GUI app, stating with QApplication/QMainWindow. It's a pity for us > experienced Swing users that already have a lot of homegrown component > we want to mix with Jambi (best of all breeds...) At the moment the support for this is on a top level widget basis, only. On Windows and Linux you can have your main windows running in Qt and popup windows using JFrame around it. On Mac OS X, Swing is required to run in the process' main thread, and so does Qt. In practice this means that Swing and Qt cannot coexist in the same VM. All in all, I personally don't forsee this as a solution one would use for releasing a product. The reason for this is that the look & feel of the two parts will be different. Both can have XP style running, no problem, but its all the smaller things, like focus handling, how hover behaves, font rendering, layoug/resize behaviour. It is possible that with a lot of tweaking this would be possible, but I would see it as a viable option, only for porting from one framework to the other. > 2) I hope you are working with a Designer plugin for IntelliJ as well, > which is favourite IDE for a lot of Java developers. It used to be mine too, when I did Java development some years back ;-) We are definitly considering this, we'll just see how many requests we get and make our decision based on that. > As a first step for > supporting IntelliJ, I would suggest that you could make a JavaDoc > version of the class documentation if that's possible so that one could > have quick help on classes/method with Cntrl-Q. This REALLY is a must > for quick programming practices. We where originally uncertain on wether to do JavaDoc or to stick with our own documentation. Qt documentation contains much more than just class docs (arcitecture, overviews, tutorials, examples, howtos, etc) they didn't fit neatly into JavaDoc. In addition our enums/flags and signals and slots are not nicely grouped in JavaDoc. This is however a reoccuring request so we may have to get working on these issues. - Gunnar
> >> As a first step for supporting IntelliJ, I would suggest that you >> could make a JavaDoc version of the class documentation if that's >> possible so that one could have quick help on classes/method with >> Cntrl-Q. This REALLY is a must for quick programming practices. > > We where originally uncertain on wether to do JavaDoc or to stick with > our own documentation. Qt documentation contains much more than just > class docs (arcitecture, overviews, tutorials, examples, howtos, etc) > they didn't fit neatly into JavaDoc. In addition our enums/flags and > signals and slots are not nicely grouped in JavaDoc. This is however a > reoccuring request so we may have to get working on these issues. > Having the docs on the fingertips via Ctrl-Q is something one really get custom to and one of the great benefits of using IntelliJ (they probably have this feature in Eclipse as well). So if you're targeting on providing a professional Java API, going for a JavaDoc extract would be an obvious thing I would say. I would rate this higher than Designer plugin... Java = Rapid Application Development -> Ctrl-Q. Helge > - > Gunnar > > >
Is it planned to put an SWT-API above the Q*-Layer this way all the great things the eclipse-Framework provides like RCP can be used and the underlying GUI-Framework could be Qt. This way applications could integrate themselfs smoothly into KDE for example. I saw that there is an eclipse-plugin (but could get it to run) so is it somehow possible to embedd the qt-jambi widgets already in say an SWT-Composite? Tom Gunnar Sletta schrieb: > Helge Fredriksen wrote: > > Hi Helge, > > and thanks for the feedback ;-) > >> 1) I see no way to mix JComponents and Jambi classes. It seems that if >> you want to use Jambi, you will have to stick to that throughout your >> GUI app, stating with QApplication/QMainWindow. It's a pity for us >> experienced Swing users that already have a lot of homegrown component >> we want to mix with Jambi (best of all breeds...) > > At the moment the support for this is on a top level widget basis, only. > On Windows and Linux you can have your main windows running in Qt and > popup windows using JFrame around it. On Mac OS X, Swing is required to > run in the process' main thread, and so does Qt. In practice this means > that Swing and Qt cannot coexist in the same VM. > > All in all, I personally don't forsee this as a solution one would use > for releasing a product. The reason for this is that the look & feel of > the two parts will be different. Both can have XP style running, no > problem, but its all the smaller things, like focus handling, how hover > behaves, font rendering, layoug/resize behaviour. It is possible that > with a lot of tweaking this would be possible, but I would see it as a > viable option, only for porting from one framework to the other. > >> 2) I hope you are working with a Designer plugin for IntelliJ as well, >> which is favourite IDE for a lot of Java developers. > > It used to be mine too, when I did Java development some years back ;-) > We are definitly considering this, we'll just see how many requests we > get and make our decision based on that. > >> As a first step for supporting IntelliJ, I would suggest that you >> could make a JavaDoc version of the class documentation if that's >> possible so that one could have quick help on classes/method with >> Cntrl-Q. This REALLY is a must for quick programming practices. > > We where originally uncertain on wether to do JavaDoc or to stick with > our own documentation. Qt documentation contains much more than just > class docs (arcitecture, overviews, tutorials, examples, howtos, etc) > they didn't fit neatly into JavaDoc. In addition our enums/flags and > signals and slots are not nicely grouped in JavaDoc. This is however a > reoccuring request so we may have to get working on these issues. > > - > Gunnar
On Wednesday 02 August 2006 11:12, Tom Schindl wrote: > s it planned to put an SWT-API above the Q*-Layer this way all the > great things the eclipse-Framework provides like RCP can be used and the > underlying GUI-Framework could be Qt. This way applications could > integrate themselfs smoothly into KDE for example. There are no such plans from our side. But your are right, Jambi makes it possible to provide an implement of the SWT-API for Qt completely in Java, without having to use any JNI hacks. I would believe the project is both interesting enough and easy enough that a group of talented Java programmers will come together and do this as Open Source software. Matthias
Matthias Ettrich schrieb: > On Wednesday 02 August 2006 11:12, Tom Schindl wrote: >> s it planned to put an SWT-API above the Q*-Layer this way all the >> great things the eclipse-Framework provides like RCP can be used and the >> underlying GUI-Framework could be Qt. This way applications could >> integrate themselfs smoothly into KDE for example. > > There are no such plans from our side. But your are right, Jambi makes it > possible to provide an implement of the SWT-API for Qt completely in Java, > without having to use any JNI hacks. > > I would believe the project is both interesting enough and easy enough that a > group of talented Java programmers will come together and do this as Open > Source software. > > Matthias Thanks Matthias. I go and search for people who are willing to start such a project or maybe there are already some of them out there? Tom
Well I gave it a try and it really seems like it's easy to provide an SWT-Layer above the QT-Jambi but: Coming back from the SWT-Newsgroups people tell me that its not possible to distribute a Lib which holds code coming from Trolltech and Eclipse in the same package which would essentially be needed. Tom Tom Schindl schrieb: > Matthias Ettrich schrieb: >> On Wednesday 02 August 2006 11:12, Tom Schindl wrote: >>> s it planned to put an SWT-API above the Q*-Layer this way all the >>> great things the eclipse-Framework provides like RCP can be used and the >>> underlying GUI-Framework could be Qt. This way applications could >>> integrate themselfs smoothly into KDE for example. >> There are no such plans from our side. But your are right, Jambi makes it >> possible to provide an implement of the SWT-API for Qt completely in Java, >> without having to use any JNI hacks. >> >> I would believe the project is both interesting enough and easy enough that a >> group of talented Java programmers will come together and do this as Open >> Source software. >> >> Matthias > > Thanks Matthias. I go and search for people who are willing to start > such a project or maybe there are already some of them out there? > > Tom
On Tuesday 08 August 2006 14:46, Tom Schindl wrote: > Well I gave it a try and it really seems like it's easy to provide an > SWT-Layer above the QT-Jambi but: > > Coming back from the SWT-Newsgroups people tell me that its not possible > to distribute a Lib which holds code coming from Trolltech and > Eclipse in the same package which would essentially be needed. > > Tom Does the Eclipse license prohibit people from writing and distributing code written with SWT of JFaces under the GNU GPL? Wow, that's really messed up. Matthias
I haven't asked in detail what the problem is but it seems like that's the case. You can not mix EPL and Qt things. I'm not a specialist in Licensing and I don't want to deal with it. It would have been really fun to start this project. I was also told that IBM already has a Qt port ready but does release it to the public because of licensing issues. Tom Matthias Ettrich schrieb: > On Tuesday 08 August 2006 14:46, Tom Schindl wrote: >> Well I gave it a try and it really seems like it's easy to provide an >> SWT-Layer above the QT-Jambi but: >> >> Coming back from the SWT-Newsgroups people tell me that its not possible >> to distribute a Lib which holds code coming from Trolltech and >> Eclipse in the same package which would essentially be needed. >> >> Tom > > Does the Eclipse license prohibit people from writing and distributing code > written with SWT of JFaces under the GNU GPL? Wow, that's really messed up. > > > Matthias
On Tuesday 8 August 2006 15:04, Matthias Ettrich wrote: > Does the Eclipse license prohibit people from writing and distributing > code written with SWT of JFaces under the GNU GPL? Wow, that's really > messed up. Yeah, very long standing problem: http://en.wikipedia.org/wiki/Eclipse_Public_License Basically eclipse is one of those few projects that gets away with GPL incompatibility (many project that tried died silently) because of the amount of companies behind it. (a.o) I fully agree with Matthias that this is a sad state and I think Eclipse will continue suffering due to that. -- [ signature omitted ]
Attachment:
pgpjZ9E6YF2QM.pgp
Description: PGP signature
Thomas Zander schrieb: > On Tuesday 8 August 2006 15:04, Matthias Ettrich wrote: >> Does the Eclipse license prohibit people from writing and distributing >> code written with SWT of JFaces under the GNU GPL? Wow, that's really >> messed up. > > Yeah, very long standing problem: > http://en.wikipedia.org/wiki/Eclipse_Public_License > > Basically eclipse is one of those few projects that gets away with GPL > incompatibility (many project that tried died silently) because of the > amount of companies behind it. (a.o) > > I fully agree with Matthias that this is a sad state and I think Eclipse > will continue suffering due to that. Wouldn't it be possible that those 2 companies get together resolve this problem I think both of them would benefit if SWT-Support for Qt would be available. The whole eclipse-framework is one of the greatest things I've used to develop Desktop-Applications and I'm not referring to the Native L&F but all those things developed around eclipse. Tom