A Year for Bug Triage
This year is turning out to be a great one for the Eclipse top-level project team - they are furiously fixing the most notorious and hated bugs in Eclipse. Several bugzilla entries that have been sitting around growing dust are finally getting their due time in the sun.
Bugs with a high-degree of visibility have a tendency to be somewhat cancerous to any project. Several of the elderly bugs that Eclipse has had hanging around have actually had very good technical reasons for not being solved, and have also often not legitimately been the responsibility of the Eclipse team to solve. It's just the nature of the beast that any issue that you have whether it's your problem or some quirk of some environment, it's going to look badly on your product.
That is exactly why it is so important for developers to think outside the box and to collaborate with other teams to solve the hardest problems; the ones that persist on and on. Thankfully, Eclipse has worked through (or is working through) several of these problems this year - and they've managed to do so with a focus on each platform.
Windows Windowing Wonders
Finally, as of April of this year, Windows XP deployments of SWT are no longer plagued with boxy circa-1995 buttons and scrollbars, and will now seamlessly inherit the Luna themes. As I mentioned here at EclipseZone, the javaw.exe.manifest problem has gone away, thanks to some clever hacking on the part of the SWT team. This problem has existed for SWT deployments on Windows XP boxes since the first release of SWT and Eclipse.
This problem has been the catalyst for so many SWT vs. Swing debates, and has also caused so many people to say things like "SWT doesn't look native" or "SWT is too hard to deploy properly" that I can't express how relieved I am to see it go away.
Mixing it up on Macs
For some time now, SWT has provided support for embedding AWT technologies (and in-turn Swing technologies) inside of SWT composites, and vice versa (putting SWT inside of AWT composites). These technologies can make it seamless to integrate the two (three) windowing toolkits seamlessly for the user (take it from someone who has developed a production product that combined SWT and Swing).
However, since the dawn of this feature, there has been one big glaring hole - no support on the Mac platform.
Once again, thanks to some clever collaboration with the Apple development team, this problem has gone away. The solution was covered here at EclipseZone
A Little Linux Love
Not to be left out, Linux is getting some attention too. For as long as Eclipse has been around, it has been noticably lacking the ability to print on any Linux platform. Over time they have introduced workarounds to use external tool support, but none of these solutions have provided the integrated polish that users expect when it comes to printing in their software.
As I just recently covered at EclipseZone, Linux is finally going to get built-in Eclipse print support thanks to the evolution of printing APIs in the GTK toolkit. This functionality is already being adopted for investigation, and unless I'm sorely mistaken, we will start to see the first cuts of this functionality showing up well before the end of this year as the new Eclipse 3.3 development cycle becomes realized.
All About the Platform
Perhaps the most exciting thing about all of these changes is that they are all parts of the enabling features of the Eclipse platform, and not specific to the IDE (in fact, in this case, they are all SWT-centric issues). That's great news for the Java community in general, not just Eclipse users - it looks like as 2006 proceeds we'll all reap the benefits of these long-standing problems just going away.
Until Next Time,
R.J. Lorimer
rj@javalobby.org
| 
Experience the future with Adobe Flex 2.0 beta now
EZ News Corner
How To Make AJAX Applications Faster, Easier?
