custom controls in SceneBuilder

[Daniel Fuchs]

On 8/31/12 2:13 PM, openjfx-dev-request at openjdk.java.net wrote:
> Message: 5
> Date: Fri, 31 Aug 2012 14:14:00 +0200
> From: Tom Eugelink<tbee at tbee.org>
> Subject: Re: custom controls in SceneBuilder
> To:openjfx-dev at openjdk.java.net
> Message-ID:<5040AA88.1010103 at tbee.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Daniel,
>
> I've tried your approach and it initially did not seem to be successful.
> So I created a stand alone FXML tests case to test, and that worked fine (screenshot attached).
> After some attempts it turns out that pressing "apply" after adding the entries to the classpath in SceneBuilder is important.
> Close does not apply them. (The word "Close" may indeed indicate that it does not apply the changes,
> but from an usability perspective I already pressed "Ok" when adding them,
> they are shown in the list; they're there, so I expected them to be already applied. FYI.)

Hi Tom,

Yeah - I've been bitten by this too - and I'm the guy who wrote
the stuff! It's definitely something we should improve - maybe
by changing the name of the button dynamically (e.g. name it
"Cancel" if some jars/folder where added but not applied).

The fact that the message still lists the types as being unresolved,
and that the Apply button is highlighted should give you a
hint that the classpath still needs to be
applied - but evidently it's not prominent enough.

I have logged
http://javafx-jira.kenai.com/browse/DTL-5182

>So it works. An annoyance of course is the fact that this must be done every time the file
> is opened.

We don't want to transparently load custom code without the user
being aware that this is happening. Imagine that someone sends you
an FXML containing classpath instructions which happen to point
to some jar also existing on your machine.

I think that by default we should always ask the user - although
we should probably have a preference that would allow to
change this and not ask again... It's a good point - I have
logged
http://javafx-jira.kenai.com/browse/DTL-5183

> So a way to add jars & folders to the classpath of the SceneBuilder at boot
> time would be highly preferable (since the classpath extend functionality
> is already there, that should not be such an issue).

SceneBuilder can be used to open different FXML files which might
point to different jars - possibly containing different versions of
the same class - so I'm not sure we should put any custom class
in SceneBuilder's classpath. IMHO that would be a bigger nest
of bugs.

> And some kind of autoconfiguration in the jar's META-INF that an icon is added to the library pane.
> Secondly, SceneBuilder does not seem to inspect the control itself;
> it has a number of properties, most importantly the "mode", which specifies if you can select
> just one date, a range, or many dates. But also "locale" and the initial value "calendar"
> should be present in the properties inspector.

All properties which are specific to the custom control itself
are put in a big "Miscellaneous" bag that you should see appear
in the inspector.

If some properties don't appear there, it may be because the
inspector does not know how to handle them.
Typically any property which is a complex bean will be
skipped. Simple enums should be there - though.

I'll try to have a look at that too.

> While on the topic of the SceneBuilder, as you may or may not know that
> I've ported the infamous MigLayout to JavaFX many moons back.
> It also has FXML support (for the test case see
> http://code.google.com/p/miglayout/source/browse/javafx/src/test/java/org/tbee/javafx/scene/layout/test/MigPaneTest8.xml),
> so I figure that third party layout managers should be taken into account as well.

I'll have a look at that, thanks for the pointer!

> Important in this case is the additional "MigPane.cc" attribute on each child, specifying the constraints.

Interesting. Today SceneBuilder has a built-in list of constraints
it knows about. At some point we will need to add some kind of API
that will allow for a custom component to declare its own constraints.
But we're not there yet!

BTW - thanks to all you guys who have taken the pain to use
SceneBuilder and try out to load your own Custom Types.
It is an invaluable help!

-- daniel

>
> Tom