Declarative styling will change how we think about Eclipse
As part of the e4 incubator effort, we’re looking at declarative UIs, and in particular declarative styling. During the Declarative Styling Roundup call we looked at both CSS and XAML as approaches.
When I’ve spoken to people about declarative styling, sometimes its difficult to convey why this is important for Eclipse, and in particular RCP applications. Typically when extolling the virtues of declarative approaches, one talks about ease of authoring, ability to provide multiple alternatives easily and out of compiled code, easier path for tooling, ability to allow graphic artists to participate more closely in the development process, etc.
A subtle but important benefit though is that it changes your expectations of what you can control.
Here’s a pop quiz:
How is the border color of the CTabFolder (the widget which implements the view and editor stacks) determined?
I actually didn’t know the answer to this offhand, despite working on the plugin based theme definition work in 3.3.
The answer is: its a static field in CTabFolder, whose value is:
borderColor = display.getSystemColor(BORDER1_COLOR);
That’s right, its hard coded to be a value determined by the OS. That’s an extremely reasonable default, but why is it the only possible value? Better yet, why have we never tried to change this as part of our theme definitions?
The latter question is the interesting one for me. First, I think its just too difficult to author theme definitions as plugin.xml entries. A proof point of this is the fact that so far the total number of add-on themes for the SDK is, well, zero as far as I know. Meanwhile, how many themes are available for your WordPress blog? Thousands and thousands.
The subtler problem I wonder is if we’ve simply not been in the mindset that we should change the borders. I’m not sure if its the platform look and feel mantra, or more of a blind spot. Certainly for me, it never occured to me to try to change the value until today.
But today, I’m taking a groovy looking mockup that Linda Watson drew for me that I’m trying to implement as a demo of our e4 modelled UI work and CSS. For those who don’t know, Linda’s hand hugely shaped the look of Eclipse over the years, so she clearly has a pretty good grasp of what comes naturally in Eclipse. How is she to remember we can’t change CTabFolder borders?
There’s a million of these kinds of hard coded (or difficult to change) look choices in Eclipse, and no designer or developer can have an accurate mental model, so I think we just end up believing that you can’t change anything, or its too hard.
I’m really liking this split between UI model, and look. The e4 demo process has been an interesting one, because I find the more I think in terms of CSS, the greater my expectation is that almost every aspect of Eclipse should be styleable. And that, in short, I believe will be a subtle but fundamental change in how we think about Eclipse.
Posted August 30th, 2008 by Kevin McGuire in category: Visual Design
You can skip to the end and leave a response. Pinging is currently not allowed.
5 Responses to “Declarative styling will change how we think about Eclipse”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
Dave Carver Says:
August 30th, 2008 at 9:53 pm
Separating content from presentation is always a good thing. It’s one of the advantages you get when you go to a true XML format to render the information. Applying stylesheets or in this case XAML, XFORM, XUL, or CSS is a big benefit. In many cases there is too much business logic mixed in at the UI level, and not enough seperation of these items within eclipse. I’m glad to see e4 looking at alternative ui rendering options.
Mike Schrag Says:
August 31st, 2008 at 12:09 am
I’ve spent quite a bit of time making Eclipse look more appropriate on the Mac and I’ve stumbled across a lot of these kind of hard-coded issues. As much as people talk about Swing, their UI separation was very powerful and allowed things that currently very hard to accomplish in Eclipse without a lot of hacking.
You can see some of the Mac work on my blog: http://mschrag.blogspot.com/2008/07/who-said-scroll-bar-autohiding.html . Any help that the Eclipse team can provide with the skinning/theming would be excellent for better native platform integration.
Ed Merks Says:
August 31st, 2008 at 12:21 pm
Linda is a goddess of design. I can’t say enough good things about her and the other graphic designers who have helped make all our applications look oh so stylish. Enabling their creativity can only lead to more goodness.
Chris Aniszczyk Says:
September 2nd, 2008 at 2:04 pm
I am so excited about declarative theming that I almost can’t contain myself.
The opportunity it presents Eclipse in terms of building a community around themes is amazing. My prediction is that once we make theming easy… we will see tons of themes available for people to use in their applications. I would love to even see us setup a ‘themes.eclipse.org’ as a repository for this type of stuff when the time comes.
Kevin McGuire Says:
September 5th, 2008 at 10:35 am
I agree 100% Chris, I am very excited about it. I like the themes.eclipse.org idea. If we saw a fraction of the themes like WordPress or Joomla enjoy then it’d be a significant advancement.
One idea I had was a “theme contest”, which the community contributes and votes on, with the winner included in the SDK download (plus some prize or recognition). Right now we have basically two themes, which seem special, almost god-given, and only the brave dare to change them. But if instead we have a dozen, or a hundred, it changes the dynamics completely.
I suspect though that breaking out of the mental cage we’ve made for ourselves will be the most challenging part!