A little Swing challenge...

Sun Feb 6 12:07:00 GMT 2005

Hello all,
anybody got some free time over the weekend? I attach the source code
for a little Swing application that *almost* works with gcj. I only
had to uncomment a few calls to JTree/DefaultMutableTreeNode that are
still missing or are implemented as stubs only. At the same time, the
app might be a nice addition to your regular Swing tests and it might
even be useful in the near future (after fixing the perfomance issues).
Perhaps someone with a current GCJ installation and AWT/Swing knowledge
can unpack and compile the .tgz and tell me whether it works?
--- About the code ---
The application is a simple Swing-based image viewer, niffler.JImageViewer.
A webstart version is available at:
http://tams-www.informatik.uni-hamburg.de/personal/hendrich/niffler
When called with a directory name, a worker thread searches for all
image files (.gif, .jpg, .png) in that directory and its subdirectories.
The corresponding file tree is shown in a JTree and flattened into a
list for direct access via an index. You can then easily view single
images, navigate to the next, previous, random images, etc. or start
a slideshow. There are several options to control image size, too,
e.g. fit-to-window, fit-to-width, original-size, etc.
I use this application as a portable (Win/Linux) viewer for my digicam
images, as well as to browse through images downloaded from websites
(wget -r style) or to search for images that I managed to lose on my
filesystem. Using the bindkeys, I can use this much faster than any 
of the 'standard' viewers (like the WinXP builtin viewer or IrfanView).
When run in a recent JDK, performance should be adequate for images
up to 3000x2000 pixels. Above that, the JDK seems to get into trouble,
e.g. browsing through Dia-Scans at 6000x4000 is terribly slow. Using
javax.imageio instead of the handwritten calls to Toolkit.prepareImage
does not improve things. But perhaps a future version of GCJ will
solve performance issues for images that large?!
BTW, the name 'niffler' is taken from the Harry Potter books. 
--- GCJ ---
On my gcj (snapshot gcc-4.0-20050130) installation, the app compiles fine
after the five changes documented in JImageViewer.java. It starts fine, 
too. However:
* the popup-menus (especially the nested menus) show up on wrong positions
 (this may be WindowManager related, I use ctwm).
* popup->select directory brings up a JFileDialog that instantly dies. 

* the JTree shows the files of the toplevel directory (because I have to
 use rootNode.children() instead of rootNode.depthFirstEnumeration())
 but otherwise is dead 
* perhaps someone is interested to implement the stub methods in Default-
 MutableTreeNode like depthFirstEnumeration() and the required methods
 in JTree?
* loading images is *incredibly* slow. Note that loading the raw image
 data and actual image rendering is pretty fast, but the call to
 Toolkit.prepareImage() seems to have a problem. On my PC (Athlon 2600+),
 I get CPU times of 50+ seconds to load a single 800x600 JPEG...

* keyboard input does not work at all. Either the JImageCanvas doesn't get 
 the focus, of keyPressed()&Co are not implemented correctly.

* the JScrollPane mostly works, but sometimes does not react to changes
 of the image size. (However, the JDK JScrollPane still doesn't work
 correctly, either...) However, mouse dragging of the image works fine!
Please let me know if and how this works for you! While the code probably
is not "FSF-quality", you may still use it as you like.
- Norman
Attachment:
niffler-gcj.tgz
Description: niffler-gcj.tgz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: niffler-gcj.tgz
Type: application/x-gzip
Size: 28262 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20050206/9b6d2331/attachment.bin>