Roo’s Ramblings

I didn’t realise how many people would actually want to look at the Jacman source. As it turns out since I released v0.4 I hadn’t made the source available (through sheer laziness). I’ve had quite a few emails and PMs and so I have finally put an end to this omission this morning.

The source is now available via the Jacman Project page.

It’s been a while but the latest version of Jacman was finally rolled out today. Functionality wise, there’s not more to report on - I’ve added some filters to the Install dialog which should be helpful for those who simply like to browse around the package repos. The application basically received a bit of a face-lift. A new look and feel looks a lot fresher in my opinion. The eye candy has also been boosted, but it’s not easy to spot unless you are using Jacman itself (try hovering over a button. Nice, eh?!)

Give it a whirl and see what you think. Also, I’ll never say no to any Java developers who wish to help out and become part of the Jacman team

I think many people who know me know I’m make quite a lot of my GUI apps in Java. Whilst I found the API a struggle at first, I soon realised that it was extremely powerful and flexible. I do believe that Java’s Swing toolkit is excellent - it’s largely spoiled by it’s poor looking cross-platform look and feel.

Still, some people may know about Jacman - a Swing app which I think it looks pretty darn good. And there’s Romain Guy et al’s Aerith which is a superb looking app. Java is powerful; Swing is powerful - where are all the desktop apps?
I therefore wanted to start something which acts as a focal point for are issues relating to Swing and the Desktop Java effort.  A showcase for good quality apps; discussion about Desktop Java issues; and a place for showing off little tips and tricks. So, SwingBling is the place to go. (Do get in touch if you are using some handy Java apps that you think others would like to know about.)
The first post was Java 6 on the desktop - part 1 which  is an overview on some of the improvements users of Swing desktop apps will benefit from in with the soon-to-be-released Java 6. (This was also linked to on OSNews).

Blimey, it’s been a while. Well, I’ve been rather busy (who isn’t?!?). I’ve had a paper accepted for a journal (which is a first for me), a paper at an international conference, and a couple of papers accepted at various conference workshops. For me, a lot of it revolves around a Arabic language processing, and a program I’ve started called aConCorde. The problem is, I don’t speak Arabic! Whilst it hasn’t hindered me so far, it’s something I’d really like to do. The first hurdle for me has been simply getting to grips with the completely new alphabet. Although I have a book, and there are many web pages with the alphabet, I wanted something to test me, and that’s why I started making a simple little app called JAlphabet.

It’s still rather rusty at the moment, which is why I’ve not actually released any code yet. But the main screen looks a little like this:

Yep, it’s another one of those pesky Java apps that I can’t stop myself from writing! However, like with Jacman, I don’t want to produce apps with the standard Java aethestics. This is clearly borrowing from Apple, with a brushed metal theme. I think it looks great, over all. What you can’t see is the fade in/out effects when you hover over a button. Of course, I didn’t do all the hardwork myself - I’ve made use of an excellent, and very flexible, Java Look ‘n’ Feel called Substance. I’m not saying my interface is perfect at the moment, but I think it’s basically there and only needs some tweaks (like window and font sizes).
Anyway, it’s very nice that I can test my grasp of the Arabic alphabet, but then came a recent challange at work where, for reasons I can’t disclose, it would be advantagous if I could understand a little bit of Japanese - or at least grasp which of the many Japanese alphabets a given word is written in. So, I’ve just started to abstract the code a little so it becomes a generic tester for any language to care to supply:

I’m currently writing a new intro screen where you get to select the language/alphabet that you wish to test. There is a basic summary screen at the end when you finish the test (or click Finish) which tells you your score and displays the items you got right and wrong. This too needs some more work, but it’s generally it’s there. Hopefully I’ll get to release the first version sometime this week.

Woo hoo! ‘About time’, I hear you cry! Or maybe not. Anyway, Jacman v0.3 is here. You’ll find:

• Multilingual supprt via a language menu (Only English and Polish at the moment - more to follow).
• Experimental system tray access to Jacman.
• Proper preferences dialog to set custom Jacman settings.
• Improved console view to see what pacman’s up to.
• ‘pacman-optimize’ button on the main screen.
• Plus many other little tweaks.

Special thanks to the Jacman team for their contributions (including the translators).

More info can be found on the Jacman Project page. (See the Readme.txt too.)

Jacman is one of my favourite projects. I had a lot of motivation to work on it when I conceived the idea. Plus, it seemed to get a good reception for its v0.1 release. However, development had pretty much ceased. This was largely due to my relocation and new job. Plus, Jon-Anders (Sonix) has a busy workload with his studies. That said, possibly the largest factor was because my motivation had faded due to underwhelming reviews.

You see, I wrote Jacman for others. I used to see many calls in the forums for GUI front-ends. I wasn’t bothered myself - I’m fine with the command line. Yet, it seemed like a cool project and I went for it. The problem is, any negative comments about Jacman is rarely about the program itself - but simply about my choice of language. Perhaps I should have known better than to use non-Free software on an otherwise Free platform. Oh, and of course, “Java is slow”. My point is that I can never seem to have a discussion about Jacman - it always goes off on a tangent about the language! Anyone who saw the Jacman thread on the forums this week will have witnessed this.

Anyway, I’ve decided not to let Jacman fade away. I’ve been dipping into the code most nights this week - just adding a few lines here and there. Hopefully the code for the next release will be stable by this time next week, after which I’ll send out a call for translators. For the releases after that, I’ve had some great ideas on how to make the user experience even better, but I’ll keep that to myself for now. Basically, my approach now is to avoid language debates and just let the program speak for itself. I still belive that of all the pacman front-ends in development, it’s functionally ahead, but I would say that, wouldn’t I?! Fortunately, Jon-Anders and I have plenty of ideas on where to take Jacman in the future to improve it in terms of functionality and usablility.

To be fair, this is hardly news. There has been a lot of work with font rendering in Mustang (Java 1.6.0) and with Sun releasing weekly builds, people have been able to test this for months.

Today was the first day for me though. No one could deny that fonts in Java looked poor (relative to other GUI libs, at least). It was possible to turn on anti-aliasing, which helped, but then they sometimes looked a little fuzzy, especially for smaller sizes. Anyway, here’s the current situation.

JRE 1.5.0 (default)	JRE 1.5.0 (with AA)	Mustang b61 (default)

I was very pleased to see the display in Mustang looking great - as they should be! Now, Mustang also supports subpixel anti-aliasing for improved rendering on LCD screens. What I’ve yet to establish is whether it was on for the above screenshots. They look pretty good, so it could be the case.

Anyone given this a try yet? It’s a Java port of the Quake 2 game. I tried it a few months ago - admittedly, I was in my Windows partition at the time - and it ran really well.

Ok, I can read your mind though: “it must be sloooow?!?”.

Well, I can’t give you my own findings, but there are some benchmarks on the site charting the progress of their port.

Here’s the table from their page:

Benchmarks being benchmarks, there is always flaws. However, I think the numbers are pretty decent. The Quake FPS test has been a pretty robust benchmark for many years. That said, testing at 800×600 seems rather too conservative. Running in full-screen mode is what seems to cause the largest issues, but it’s hardly sluggish.

Saw an excellent blog, by Phillip Eby, almost a year ago, and a friend of happened happened to recall it recently in a discussion about Python. It’s titled Python is not Java and talks about how adopting a Java approach when programming in Python just makes life difficult. In particular, I love the section about overuse of XML:

If you are a Java programmer, do not trust your instincts regarding whether you should use XML as part of your core application in Python. If you’re not implementing an existing XML standard for interoperability reasons, creating some kind of import/export format, or creating some kind of XML editor or processing tool, then Just Don’t Do It. At all. Ever. Not even just this once. Don’t even think about it. Drop that schema and put your hands in the air, now! If your application or platform will be used by Python developers, they will only thank you for not adding the burden of using XML to their workload. [Phil’s emphasis]

Now, it takes a brave man to be critical of any programming language. After overwhelming response from readers, he followed up with Java is not Python Either. It’s nice that he balanced the argument somewhat. His argument is in fact somewhat lacking, and it basically boils down to Java is good because it has generated a lot of good frameworks that are then ported to other platforms. He confesses to taking scraps from the Java table on many-a-occasion in order to avoid reinventing the wheel within a Python project.

I personally am a fan of both languages. The trick is to simply pick the strengths of a given language to match the needs of a given project.

The HTML rendering component in Java Swing is so dated it’s become a joke. HTML 3.2 compatible with a little bit of support for CSS thrown in - it is not capable of displaying modern websites. Recently, the Flying Saucer project has been delivering a compontent OSS XHTML renderer, which has proved very successful. However, it’s still behind the big names, like Firefox, Opera, Safari, etc.

Jrex does things differently. As useful a Java implemented renderer is, Jrex allows you to embed the Gecko rendering engine, which is used in Mozilla-based products, directly in to your Java app. The Gecko engine has the advantage of being a large project with a lot of man-hours already dedicated to it. It’s up-to-date, robust and pretty speedy. So, I’m very glad that this is available.

I thought it was interesting to see that Adobe have released their own PDF API in Java. Sure, it’s only a viewer Javabean, and it’s not open source. However, it’s free to use and it means you can integrate PDF viewing and printing into your applications.

Java.net published an excellent tutorial on making use of this component. When combined with other libraries, like iText - a Java API for PDF generation - then you can have pretty good setup for reading/writing portable documents.