Integrating Java Swing with Oxygen
Thom Castermans
A brief introduction: I am an undergraduate student in Eindhoven, the Netherlands, studying Computer Science and Engineering.
Together with a friend, studying the same as me but also Mathematics, we noticed how ugly Java Swing applications look in KDE.
This is logical, since Swing does all the drawing itself. However, we, geeky as we are, decided this should be improved. First we
searched a bit for a LAF (Look and Feel) for KDE. We found something that was made for KDE 1.0, so that's nothing really. Then,
we looked at the possibility of having KDE render everything for Java. We still are trying this (mostly for native text rendering), but
we haven't figured out yet if this is possible and if yes, how.
Then, we started working on a LAF that should integrate Swing applications with Oxygen: Joxy was born. At the moment it is in prealpha
and version 0.0.2 is available at SourceForge: https://sourceforge.net/projects/joxy/. Both of us don't have lots of spare time, but we do
our best to make it look as good as we can. The obvious goal is a pixel-precise KDE-look (but its far from that right now) :-)
Now the reason I'm sending this mail is because I hope to get some feedback of you. What do you think about it, possible improvements, etc.
Also, it would be nice if some of you guys with the real knowledge of KDE's rendering code would look at it. For most UI elements we have
created, we looked at the actual KDE source, but since we are infant C++-programmers and KDE is quite a lot of code, we did not get all of it.
Lastly, a bit of awareness of our project is always good, right? :-)
Cheers,
Thom and Willem
Shantanu Tushar Jha
Hugo Pereira Da Costa
as far as I know there is already a way to force java swing applications to use your gtk-2.0 theme.
see: https://bbs.archlinux.org/viewtopic.php?id=72892,
as well as: https://bugs.kde.org/show_bug.cgi?id=273829
(although as far as I remember it is a pain to make it work properly. I remember I did succeed once, but trying again now, I miserably fail)
This, combined with oxygen-gtk makes a fairly good job at using oxygen for swing applications.
Now
1/ I'm no expert at java stuff
2/ have my hand pretty full already with oxygen-qt, oxygen-gtk, oxygen-gtk3, and oxygen-transparent.
So that I am sorry to say, I have zero time to allocate for yet another toolkit :(
Hugo
Hugo Pereira Da Costa
kde-workspace/libs/oxygen/
and
kde-workspace/kstyles/oxygen/
Alex Richardson
Hi,
I like the idea of having a KDE L&F, although the GTK L&F combined with oxygen-gtk
almost do the job.
The screenshots look very promising.
I think the best way of doing this is letting KDE do all the drawing. This would mean the
program would still look native even if someone is not running the Oxygen style.
However this means that almost everything would have to be done in C++.
Since you say you are not skilled in C++ yet, that means it would probably take longer
to implement.
I had a quick look at your native code and found a few issues:
You instantiate a new QApplication everytime the method is called, you should only be doing this once.
I.e. add a new native method that you call from the static class initializer.
This method could also look up all the field/method IDs so you have them cached.
There are two memory leaks:
QImage* qimage = new QImage(width, 30, QImage::Format_ARGB32);
QPainter* painter = new QPainter(qimage)
You don't delete these, so they leak (C++ has no GC)
Better way of doing it is allocating them on the stack:
QImage qimage(width, 30, QImage::Format_ARGB32);
QPainter painter(&qimage);
You set the BufferedImage pixel by pixel. Calls from C++ to Java/Java to C++ are a lot more expensive
than C++ to C++/Java to Java since they cannot be inlined and hava some additional overhead
compared to and ordinary function call (registers get saved, etc). It would be better to use the
setRGB method that takes an int[].
Printing strings may not work if they contain non-latin1 characters
when you call painter->drawText() the const char* is implicitly converted to
a QString, which doesn't always assume UTF8 as encoding for const char*
QString::fromUtf8() would do the job.
However this is inefficent because QString and java.lang.String both
use UTF16 characters, so it would be better to use env->GetStringChars(),
then QString::fromRawData to get a QString, and once it has been drawn
env->ReleaseStringChars().
Alex
Hugo Pereira Da Costa
> Hi all,
>
>
> Shantanu: a funny coincidence indeed :) We are trying our best to make
> it as good-looking as possible. I am aware of the OOo/LO integration,
> but they do not use KDE settings or rendering, AFAIK. Its more that it
> looks 'a bit better', not as clumsy/ugly as it does without the
> integration. Thanks anyway :)
>
> Hugo: maybe I should have mentioned that too, but we are aware of the
> GTK L&F and oxygen-gtk package. It definitely looks pretty good, but
> we wanted to make it look even better. Not saying we are going to
> succeed in that, but as said, we try. Anyway, its always good to try
> and make it as straightforward as possible, right? So if it is not
> necessary any more to use GTK, that's only good I think. I do know on
> how many projects you are working :) I've been using Oxygen
> Transparent for a while, which is beautiful! Furthermore I think I've
> spotted 'some' lines you wrote in the Oxygen theme, right? Anyway,
> thanks for giving us feedback, we appreciate it.
Hi Thom,
I agree that using the gtk binding to java swing + oxygen-gtk is far
from perfect (many widgets are not themed; many oxygen-gtk features have
to be turned off, etc.) and that your screenshots look more promising.
Good luck !
Hugo
> Alex: huge thanks for looking at our code! As I mentioned above, we
> are definitely aware of the GTK L&F. I completely agree with you about
> letting KDE render everything. The only real reason we are not doing
> that right now is that we simply didn't/don't know how to get that to
> work. And even if one gets it to work, it should be fast, since you
> don't want a L&F to make a GUI slow (well, not slower than an average
> Java GUI is at least), which is hard for infant C++ programmers I
> suppose. We will certainly have a look at it though, certainly now we
> have this small piece of code working for the text rendering. Then
> again, thanks a lot for your feedback on our tiny piece of code, that
> contains so many bugs apparently :) We have fixed most things you
> mentioned (I believe Willem did yesterday, but I think he didn't
> commit the changes yet), although I'm not sure if Willem already
> managed to make the 'image copying process' faster already and if he
> worked on the strings. He did say not creating a new QApplication on
> every call made the drawing lots and lots faster already, so that's
> good. In any case, the changes will be on Git soon and I think we are
> going to let more components be drawn by KDE soon as well.
>
> Thom
Alex Fiestas
since I'm a KDE user (quite a few years now :p)
What about open/save dialogs?
Notifications?
SWT?
:33 Thanks and great job !
Thom Castermans
> I'm going to just let my excitation talk by me since I have been missing this
> since I'm a KDE user (quite a few years now :p)
>
> What about open/save dialogs?
a decent file chooser. Obviously, here it applies too that a native
file chooser would be the best, but we will have to look at that.
Currently, it is possible to select files in a chooser that is, well.
Ugly. The buttons are KDE-ish, but that's it. The rest is styled by
the Basic L&F, which is not really KDE-ish at all as you would have
imagined I guess.
A to-be-done really, but we're working on it.
> Notifications?
By notifications, you mean the 'global' notification system? We didn't
really think about implementing that yet.. I'll talk about it with
Willem. Good suggestion!
> SWT?
That's a tricky one. SWT uses, AFAIK, Gnome widgets. At least it is
not trivial to apply a custom styling. Joxy is, at the moment, a L&F,
which means only Java Swing applications are targeted. If there is a
way to style SWT we would like to here about it. Maybe an idea for
some sort of side-project... Joxy-SWT :) Oh wait, Joxy is a
side-project of my study already :)