An unrelated problem drew my attention to the Understanding Layouts in SWT article. It’s always bugged me that the many screenshots in this article are represented in JPEG format. JPEG is a lossy format that, in my humble opinion, is inappropriate for screenshots as the images end up with odd dithering that just plain bugs my eyes. So I decided to rebuild the screenshots in PNG format.
When I updated this article in 2008, rather than build and shot each image manually, I wrote a little Java program that builds and shoots all of the images automatically in one fell swoop. At the time, I couldn’t figure out where to store the code; it didn’t belong to any Eclipse project, and the way that Eclipse Corner is set up in CVS makes it an inappropriate place for Java code. At the time, I stuffed it into a private CVS server and forgot about it.
I pulled that code out today, tweaked it a bit, and regenerated the images. I think they look a lot better in PNG format.
I’ve put the code into a repository on GitHub if you’re interested. I’m not sure if it’s a great example of how to bend SWT to your will, but there is a little trickery in there that gets the job done.
Oh… and some food for the trolls: SWT is way better than Swing. FWIW, I haven’t looked at Swing in years; what do I know?
Eclipse Hints, Tips, and Random Musings 
Yeah, but JFace sucks it. 🙂
And yet in 2012 I still cannot change the background color of… menus. Has this changed recently? I have CSS with E4, but I can’t change background color of a menu item. Because SWT doesn’t support it. Isn’t that silly?
I don’t know about silly.
There is an open bug, but it seems to have stalled due to lack of interest. Perhaps if you weigh in on it, it might move forward.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=168716
Hi Wayne,
I’m not sure what we (end users) can do (except giving votes) to this kind of bugs.
I wouldn’t say that there isn’t enough interest for this feature. It’s just sad state that people learn to live with this kind of limitations at the core of the platform. At first we watch the bug, then we see how it gets postponed from milestone to milestone, then it’s too late to implement this kind of a feature before next major eclipse release, then we start working on other projects (and leave eclipse land). Two or three years later somebody mentions SWT and we remember our favorite bug and it’s still there, open, unresolved.
The bug I mentioned is not trivial to fix (obviously) but I believe that this one deserves mentioning. I think that it will get more visibility when people start using E4.
I’m writing all this because I think you might push this one to somebody who can do something about it.
ilx, I think you’re missing the point of open source projects like Eclipse. The community drives things by being involved. he first level of meaningful involvement includes things you’ve done, like writing blogs, filing and commenting on bugs, etc. But that’s the easy part; anyone can point out faults or ask (or demand) things that they consider important. The really meaningful involvement means rolling up your sleeves, digging in, and getting your hands dirty. When there is a feature or bug that goes unresolved for a while, it’s because there is no committer motivated to work on it, which can mean a lot fo things, such as no employer willing to pay an employee who is a committer to do it, or no individual committers who consider it more important than the mountain of other items on his plate. And that’s the key to keep in mind – there is WAAAAY more work to do than willing people to do it.
Getting involved at this level isn’t as hard as we often think; in fact, for a long time the e4 project was granting committer status to just about anyone who expressed interest in becoming a comitter.; it might even still be that way. SWT committership is, obviously, more work to obtain, but it IS realistic to get the code, understand the relavent area, and provide a patch. I’ve done it several times, on my own spare time even. My point is, if you want it fixed and nobody seems interested in fixing it for you, make like Nike and Just Do It.
Eclipse can only be as good as we all, collectively, drive it to be. Nobody has the right to sit back and complain about something they want to be changed if they are unwilling to get their hands dirty and make the change themselves.
> I’m writing all this because I think you might push this one to somebody
> who can do something about it.
This may come as a surprise, but the Eclipse Foundation doesn’t actually employ any of the software developers on our many open source projects. All of our developers come from the community.
Our open source projects are a place where people from different organizations and backgrounds come to work together. They balance their own requirements with those from the community, pool their resources, and make decisions together on what they have the ability to implement. The best way to influence that process is to become part of it.