[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Integrating Java Swing with Oxygen
From:       Alex Richardson <arichardson.kde () googlemail ! com>
Date:       2012-03-27 12:45:50
Message-ID: 5229324.4fDYkQ8vih () alex-desktop
[Download RAW message or body]

Thom Castermans schrieb am Sonntag, 25. März 2012 11:09:56
> Hi all,
> 
> 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

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





>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]