Change existing controls or create new ones?
jonathan.giles at oracle.com
Wed Mar 13 17:06:14 PDT 2013
Good questions. I'll do my best to answer them quickly now.
Regarding the transformations and their lack of inclusion in layout: the
reason for this is that more often than not a transformation is a
temporary thing (for example a rotation / glow / drop shadow on mouse
hover), and it is not desirable that the layout of your user interface
be impacted by these transformations / effects (imagine a wide but short
rotating rectangle node pushing / pulling all nodes around it as it goes
through its 360 degree rotation).
However, in saying this, if you do want your layout to be impacted by
these transformations / effects the solution is simple: you wrap your
Node in a Group, and place that Group in your scenegraph.
To slightly deep dive (and I hope I'm right here - it's been a while
since I've had to explain this), a Node has a few different layout
bounds. The two most relevant to layout are 'layoutBounds' and
'boundsInParent'. The layoutBounds is actually what is used to determine
sizes / positions of nodes in a layout, but this does not include
transformations / effects. These impact the boundsInParent instead. The
thing a Group does is gather together the boundsInParent of all of its
children and make that its layoutBounds. This is why placing a Node with
transformed boundsInParent will be used if you wrap it in a Group.
Switching to custom controls / customised controls, in general the
recommended advice depends on the requirements and availability of a
suitable control to base customisations on. I would say the best general
advice is to firstly try getting the look you want by just modifying CSS
on a custom control. If this works then you're great and can stop. If
this doesn't work then you could consider either extending or developing
a custom Skin for the control, but this brings with it an expectation
that you will support all API from the control class (which is often a
One piece of advice I always give when I do conference sessions on
custom controls is that you _do not_ have to build UI controls by doing
it the way we do it in the UI controls team (that is by extending
Control, SkinBase, etc). The only reason why you would do this is if you
want to ensure maximum ease of distribution to third parties and the
highest level of CSS skinning opportunities (but in saying that I don't
think it is much greater than simply doing it the way I normally
recommend, which is to extend Region and throw together your UI by
adding children to the Region node).
I hope that makes some degree of sense...
On 14/03/2013 12:35 p.m., Philipp Dörfler wrote:
> the question might benefit from a short example:
> Some days ago I created a prototype of a TabPane  and then tried to achieve the same look by styling the already existing TabPane with CSS. The latter was not quite as successful, though  but I did not have the time to investigate much further. I know that it is possible to adjust the .tab-header-area's dimensions with CSS but as the dimensions of that header does not seem to obey the boundaries of the rotated tab, I would have to manage the tab-header-area's height (or width that is) manually.
> The underlying problem here is that the JavaFX layout managers do in general not account for transforms, so scaling, rotations and translations result in the node crossing the container's boundaries.
> I do not want to question whether this is "expected behavior" or not - I assume there are good reasons for the way it is implemented right now (and be it only the possibility of 3D transformations - and how should those be handled by container panes?).
> No, my actual question is:
> What is the preferred way to achieve a reusable TabPane which looks like ? Should one try to style the existing one using CSS and Skins or is it better to create a control like this from scratch? Just assuming the first were possible in this example (and it probably is), here are some quick pros and cons. I'd be happy if you could contribute some of your own:
> Style existing controls:
> - Better support for assistive technologies, screen readers (it's a TabPane, we already know how it works)
> - => more semantical information
> - already implemented functionality
> Start from scratch:
> - Greater flexibility in creating the visuals (wild guess - I have not bothered trying Skin myself, yet)
> - no functionality implemented - you have to do every single thing yourself
> - less semantical information (the screen reader or automation software does not know how a CustomFancyTabPane works)
> Might someone who has a deeper understanding of controls shed some light on these questions, please?
> Oh and - those reasons for not taking transformations into account... I'd be interested in them, too.
> ~ Philipp
>  https://twitter.com/phdoerfler/status/308361970611023873/photo/1
>  http://cl.ly/image/300M0q3k2u38
More information about the openjfx-dev