Painting the Workbench
If you’re a UI developer in Eclipse, you probably come across one of these issues:
- fighting layouts
- fidgeting with margins
- pushing pixels
- etc…
You probably also came up with some hack to add borders to composites to help with these issues. Well, at least I did.
Why am I bringing this up? Well a few days ago, Simon Archer and I were discussing how new GridLayout() can be bad since it sets default margins and how it can be difficult for people to realize this amongst other layout issues. To ease some of these issues and stop the madness of duplicating debugging utilities, Simon and I decided to start a new work area in PDE called Picasso. The purpose of the Picasso work area is to provide a utility to help UI debugging. Picasso does this by painting the workbench in funny ways to aid debugging 
The screenshot above shows Picasso painting the preferences page’s composites. Picasso also allows you to hover over widgets and provide some raw debug information.
How do I use Picasso? Simply grab the code from the PDE Incubator and launch some runtime workbenches. Or you can build yourself a version of the Picasso plug-in and drop it in your application to see what’s going on.
Note, Simon and I are just providing Picasso as a utility for people to use, we don’t have crazy plans on maintaining it unless the community steps forward with patches and ideas. It’s just a work area that maybe useful to some.
Enjoy.
Hi Chris,
is there a relationship between adding color and debugging facilities. I am getting so confused about the various colors. Can it only do debugging because of the colors ?
christian campo
The colors represent a different composite. That’s all.
This aids debugging by colors composites for you so you can see any layout issues really easily. You can than hover over the composite to see the various raw layout information (ie., margin width).
It’s a very simple debugging utility to help visualize how you or someone else layout their composites.
Does that make a bit more sense?
Very nice!
I’ve written something form SWTBot that’s based on the SWT Spy. Checkout a screenshot here: http://ketan.padegaonkar.name/swtbot-spy.png
Shows info on whatever control you hover on.
What I’ve got is just good enough for folks to find their way though. Would it make sense to have a better debugging and introspection utility for SWT controls ?
Ketan, I would love to see more advanced introspection utilities for SWT widgets. I think the current trend is that people just right their own utility classes for debugging purposes.
Very cool. Currently my layout-debugging tool is Jing, the screen-capture utility from Techsmith. Sound strange, but it highlights composites and widgets on a mouseover when creating screen-captures
The PDE incubator does not strike me as the right place to house this effort, as it centers around general UI development, not bundle/plug-in development.
The Platform incubator seems like a better fit.
Pretty cool, though it look more like Mondrian to me.
That is too funny, I will all the time color my composites manually using composite.setBackground(…) in order to debug layouts. No more, thanks to you!
To integrate this into my environment I added a .options/tracing file and modded the Activator class accordingly.
I can send a patch along if you’re interested.
Greg, can you file a bug against PDE Incubators with a patch?
The approach of using an options file seems fair.
Wassim, the reason this is in the PDE incubator is that this does help plug-in developers and mainly, I’m too lazy to push this elsewhere at the moment
Interesting…….I am a global painting manufacturer supplier and looking for partners globally. If any one interest please contact me through this website.
Helpful !!!! I often modify my UI code in order to set background color for all my composites.
Manu
Nice. I typically do that by hand by setting the background color on trouble composites. But this would be nice to have in the toolbox. Thanks!
Isn’t it a bad idea to affect SWT directly just in case some code relies on some property being set? I would have thought that a better idea would be a translucent layer on top which can be turned on or off, and does not mess with the SWT stuff.
Do you know the UI Inspector for Eclipse (http://rcpinspect.sf.net/) which shows similar information but is not so colorful and impressive as your fine tool?
Cool. I’ve found similar handy debugging CSS, I imagine the same would be true for Eclipse.
As you know, for e4 EricM has been working on a tool which introspects the UI to produce a model. Seems there’s a tie in there (e.g. your debug utility could be a transform on his model).
By the way, it is worth to mention that SWT Designer can eliminate needs for such debugging. For example this UI is created completely in SWT Designer, so editing all the padding and laying out components was real pleasure.
yes, a UI designer can help in a lot of cases. In cases where you are trying to analyze another product or softwares UI… a UI designer is hard… Picasso gives you a way to do this.
btw Eugene, do you get a dollar for everytime you mention SWT Designer
? (I had to say it ;p)
I always intended this tool to be the poor-man’s UI designer. Part of its beauty is that it is “caveman technology”. Of course, Chris’ work to integrate it into every launched workbench makes it accessible to everyone. I love the way that everyone’s dirty laundry is on view for all to see.
But, joking aside, many SWT layouts can benefit from being reviewed using this tool.
Excellent work, guys! I had this real head-scratcher layout problem. Couldn’t figure out what could possibly be going wrong. Then I remembered reading about Picasso a few days earlier. Gave it a try and it let me figure out that I wasn’t going crazy… I was looking at a bug in Linux SWT. What a relief!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=241840