JavaFX FlowPane vs. FXFluidFlowPane
We're still working on our JavaFX UI implementation for JVx. Some weeks ago, we worked with standard JavaFX layouts (layout panes) like BorderPane and FlowPane. Both layouts are useful but don't work like BorderLayout or FlowLayout from AWT/Swing. There are small differences, e.g.
It was possible to resize a BorderLayout to any size. The BorderPane checks minimum and maximum size of its nodes and doesn't resize if bounds were reached. Sure, that's useful in theory but bad in practice because the content of a screen should always resize to the screen size (e.g internal frames).
The requirement wasn't hard to implement. We now have our own FXBorderPane which has its own min. and max. calculation.
The standard BorderPane was very useful but the standard FlowPane wasn't, because it has bigger problems/limitations:
- Overlapping of Wrapped FlowPanes with other nodes
Overlapping
- Size calculation depends on prefWrapLength if not stretched to full-size (BorderPane, SplitPane, ...). This means that the pane doesn't grow automatically if the parent has enough space.
Width calculation
- The FlowPane doesn't support alignment of managed nodes
Standard FlowPane (centered nodes)
but should:
Fluid flow pane (bottom aligned)
Fluid flow pane (stretched)
We solved all problems with our FXFluidFlowPane because our applications won't work with standard FlowPane.
In JVx applications, we have more than two layouts. The most common layout is our FormLayout. We already have JavaFX implementations for all JVx layouts, like FXFormPane or FXNullPane.
Here's screenshot of our FXFormPane test application:
Form Pane
Development | rjahn | 28/03/2015 8 Responses to “JavaFX FlowPane vs. FXFluidFlowPane”
Leave a Reply
RSS-Feed
Nice one
Interested in contributing the layouts to open source? I've got fluent versions of the normal layouts in JFXtras, these layouts would be a great contribution.
Not sure, if you think that our JavaFX UI and of course, all controls, layouts, ... are commercial?
We thought that the header in the source files is enough, e.g.: Link
But to be sure: Our JavaFX UI source code is already open source, with Apache 2.0 license.
Let me know if I misunderstood you.
No, I was not expressing myself correctly. Yes, the code is open source, but it is part of the JVx framework. These layouts could be very beneficial in a less focused distribution.
Okay. It's not soo easy because we're talking about open source
First: JFxtras is a great set of very useful JavaFX extensions, from professional developers, freely available!
Our "problem" is that we must take care of the legal situation. Are there CLAs for JFxtras developers? As well, who is responsible for the created work? Who is responsible for the development or who is responsible for the quality? What about an official roadmap, service contracts, ...
If you're an individual developer, it's not a problem to contribute your code, but it's a little bit complex if you're a company and plan the integration of OS in your commercial product.
We use all our open source frameworks/libraries in our commercial product VisionX, and we offer service contracts with different scope of services. It's important for our business model to be responsible for the development. Sure, it would be possible to do the same under a foundation like Apache or Eclipse. But currently, it's easier to manage as SIB Visions.
Right now, our business model is based on an open source strategy with full control of above things.
No problem, it was just a question.
JFxtras is released under the New BSD licenses, which basically means that you are free to use it, but no one is responsible for any damages. So placing in JFxtras is not a risk.
JFxtras has a CLA in which claims of the developers are released, so there is no claim there. And for who is responsible... We kinda work by the principle that the author is responsible, because no one likes to hack around in other people's code.
Open source usually has nothing officle, being it a roadmap or service contract, by the open source developers themselves. That does not prevent any company from providing commercial support, though.
Thanks for sharing your thoughts!
Hello Tom.
The thought of getting the additions/new stuff we are creating upstream, or in a more common library, has crossed my mind a few times, yes. But there are quite a few things to consider before any of that can happen.
1. We're releasing under Apache License v2.0. We'd (most likely) need to relicense our work to get them upstream/somewhere else. This is obviously easily possible, but might have a few implications which we need to be aware of (and which we haven't thought about by now).
2. Control. As rjahn said, these components will be an important part of applications for our customers. Having the control over them allows us to react fast and swiftly and make decisions without having to wait or depend on anyone.
3. We'd need to get involved with the project we contribute to. That might sound stupid, but such "duties" can consume time. Time we might have spent doing something different or simply doing what we wanted to do in the first place.
Especially the second point makes it quite complicated to have these components "somewhere else". Though we could go the same way as with the default components (wrapping and extending them) if necessary.
One possible solution would be to "gift" a copy under the license needed (basically a fork), but I'm not a friend of such duplication as long as it can be prevented because the two copies might drift apart feature-wise.
But the least we could do, once we merge all this to trunk/master (note that all of this is still in the dev2015 branch), is to provide multiple build targets with ant. Something like "jvx-javafx-core.jar" which only contains the basic components, "jvx-javafx-databinding.jar" that contains all the databinding components for our model and "jvx-javafx.jar" that contains everything. That is rather easily done, not a lot of work and makes reusing a lot easier for everyone else.
As with adding them to OpenJFXtras, personally (and I mean personally) I think it's an interesting thought and we should not simply sweep it under the carpet and call it a day. Right now we're still developing and things may change quite rapidly, but once we're merging all this to trunk/master it should be stable (as in API and feature-wise) and we should have a look at this idea again.