e(x)clipse 0.0.3 released

UPDATE
Please download the latest version from efxclipse.org

Back from holiday a lot of company work I’ve been unable to implement a lot of new things for e(fx)clipse but I’m still making progress improving the current implementation. I’ve improved the validation of css styles, fixed some language definition stuff to improve CSS-compability, … .

The really cool thing about the CSS-Editor is that one can implement ones own validation rules, attributes using OSGi-Services. So one could e.g. write an extension which understands webkit specific features, or one for SWT-CSS.

Still my main focus is support for JavaFX-CSS but here’s the main problem with it: Some of their CSS-Definitions are simply invalid if one takes a close look at the CSS-Definition. What do I mean with that? Look at this example of a linear gradient:

.test {
  -fx-background-color: linear (0%,0%) to (100%,100%) stops (0.0,red) (1.0,black)
}

which is simply invalid because a function call has to have a name which is not the case. While this problem is not fixed at least in a way like this:

.test {
  -fx-background-color: linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
}

It’s impossible to implement a CSS-Compatible tooling – so my hope is that this bug gets fixed though I’m not sure this will happen. And because we are at it definitions made up from many terms like the gradient above makes validation of definitions like this unnecessary hard to implement:

-fx-border-color <paint> | <paint> <paint> <paint> <paint> [ , [<paint> | <paint> <paint> <paint> <paint>] ]*

If you take the example from above this means one could define a CSS like this:

.test {
  -fx-border-color: 
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black),
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
}

or even worse

.test {
  -fx-border-color: 
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   radial (25%,25%) , 50% focus (20%,20%) stops (0.0,gray) (0.50,darkgray) (1.0,dimgray) reflect
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black),
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
   linear (0%,0%) to (100%,100%) stop(0.0,red) stop(1.0,black)
}

Do you see the “,” in between the radial gradient definition? Argh. I think every value should be a sole function term with subterms and I hope it gets implemented like this.

Anyways I’ve uploaded release 0.0.3 to my git-repo.

Beside working on the CSS front I’ve also started looking into the WindowBuilder sources to understand how one could implement support for the Java-API and fxml but it is going to take a lot of time until I can provide something useful.