Swing had LayoutManager's separate from the containers. So far as I can tell, JavaFX doesn't do that.
I have a complex structure of nodes that I want the user to be able to toggle between several different layout approaches. Something equivalent to the user specifying flow and all containers are converted to the equivalent of FlowPanes. Then they could choose vertical and everything is laid out vertically.
Is there a way to do this other than swapping out the nodes/recreating the whole structure?
I should note: the hierarchy changes at runtime and it is deeply nested.
I mention Swing because this is straightforward to do in Swing by maintaining a list of all containers in the entire hierarchy, and with a simple loop (or tree traversal without the list) setting a new LayoutManager on them. JavaFX doesn't seem to have this possibility because the layout behavior appears to be internal to the nodes.
Isn't something like this working ?
AnchorPane main=new AnchorPane();
AnchorPane sub1=new AnchorPane();
sub1.getChildren().add(btn);
main.getChildren().add(sub1);
When you want to switch the layout
AnchorPane sub2=new AnchorPane();
main.getChildren().remove(sub1);
main.getChildren().add(sub2);
Edit
I guess I missed how you are doing layouts. This is how I envisioned it.
Definitions to Various Components
MainLayout
-> CustomLayout 1
-> References to various components. ( Essentially you are not creating all the components for every layout, rather you are referring to them in each layout )
-> CustomLayout 2
-> References to various components. ( More or less a different arrangement of the same components, adds some component references and removes some )
-> CustomLayout 3
-> References to various components.
Making a bold statement, but if there were a tool in JavaFX, how would it do this automatically ? Each template needs to know where it should render a particular component and arguably the easiest way to do this is just create a new template that arranges the components in a different layout and swap the template when user wants to see a different layout.
This is not easy to do in Swing. You would still need to set all the layout constraints on the individual components again, unless your layout is very straightforward.
I don't see how there is much difference in this between swing and javaFX. In JavaFX you would need to add the same controls to a different container (VBox, HBox etc.) but you still don't need to recreate the controls every time. It is a little awkward to find the containers in the middle of the node hierarchy but I'm sure there is some kind of elegant recursive solution :)
Related
Think of an RPG game where you might need to present a list of buttons. A user might enter a room where they have to select from a series of options (buttons). Is there a type of container/panel that would show clickable buttons horizontally, but wrap if needed?
The best analogy I can think of to picture the situation is, Imagine needing to click on an item in a backpack, but each item is potentially a different width. (I can make them all the same height but the width then varies)
.---[My Backpack]------.
| aaa bbb cccc ddd |
| ee fff g |
| |
| |
`----------------------'
(The options come from a database, so its unknown at compile time how many options might be in a room, so I am going to need to programmatically add options.)
The very bottom of this godot document introduces custom container layouts, but it's unclear to me how this would work in practice
Flow container for Godot 3.5 or newer
Godot 3.5 (currently in beta) introduces HFlowContainer and VFlowContainer that will serve the propuse described.
The HFlowContainer will fill a row and when they overflow, it will add a new row and continue there. The VFlowContainer will work on a similar fashion but with columns.
Flow containers before Godot 3.5
For older versions of Godot you can use the HFlowContainer addon which you can find it in the asset library (here). Note that there is no VFlowContainer counterpart.
As everything on the asset library it is free and open source, so feel free to read the code and modify it, which can be serve as starting point if you want to make your own custom Container.
Making your own custom Container
The gist of making a custom Container is that it must position its children.
For that effect you react to NOTIFICATION_SORT_CHILDREN in the _notification method. You might also want to react to NOTIFICATION_RESIZED.
You can have a method - which I'll call layout - that you call when you get the notifications:
func _notification(what):
if what == NOTIFICATION_SORT_CHILDREN:
layout()
And also call layout from the setters (setget) of the properties that define how the Container must organize its children. To call layout from anywhere other than _notification, you might want to use call_deferred("layout") to prevent any possible re-layout loops from hanging or crashing the game.
The layout method would iterate over the visible children Controls and use get_combined_minimum_size to figure out their size.
Something like this:
func layout() -> void:
# …
for child in get_children():
var control := child as Control
if not is_instance_valid(control) or not control.visible:
continue
var size := control.get_combined_minimum_size()
# …
Then using that information compute the position and size for the children Controls. When there is room for the Controls to grow, you may want to split it among them according to their size_flags_stretch_ratio.
Once you have the position and size for a Control decided, use fit_child_in_rect to position them, which will take into account grow and size flags.
Thus - barring the simplest Containers - you will need to iterate over the children Controls twice. And for that you might find useful to have an auxiliary data structure to temporarily store them.
I'm developing an Xamarin Android Mvx5-beta application. When running on a small-screen device, I want to show a drawer navigation using the Toolbar and the hamburger-icon. On larger devices, e.g. tablets, I want a different layout conaining three columns. No drawer navigation but a static panel with navigation options and two other panels for content.
I started with the examples XPlatformMenus and Fragments to get a drawer navigation layout combined with the use of activities (with fragments) in different layouts qualifiers, like:
Question:
Using this approach, Android automaticly looks for an activity with the same name (e.g. main_activity.axml) in the appropriate layout-qualifier folders. But on the larger screens I don't need a drawer layout and I do need an extra column. The Mvx-viewmodel does not yet know what layout to render, so it just calls:
ShowViewModel<HomeViewModel>();
ShowViewModel<MenuViewModel>();
These ViewModels, for example MenuViewModel, are registered for fragments that require a navigation_frame, as shown in here:
[MvxFragment(typeof(MainViewModel), Resource.Id.navigation_frame)]
[Register("mydemoapp.droid.views.fragments.MenuFragment")]
public class MenuFragment : MvxFragment<MenuViewModel>, NavigationView.IOnNavigationItemSelectedListener
{
<..>
}
So, rendering this same Activity in layout-sw600dp requires a navigation_frame. Which I don't want on these larger displays.
What would be the preferred design choise in this situation? I can think of two:
Show/hide elements in the Activity programmatically by querying the screen info
Don't make use of layout qualifiers, but design complete seperate Activities for larger screens and based on screen size let MVX Show ViewModel-A or ViewModel-B.
Any advice would be appreciated, many thanks in advance.
I think it depends how different your layout need to be between large screen and small screen form factors.
Few UI differences
In addition to using different layouts, you can define a bool property in your XML values resources that is different between standard and sw-600dp
values
<bool name="is_large_screen">false</bool>
values-sw600dp
<bool name="is_large_screen">true</bool>
You can then read this value in your Android views and prevent methods like ShowViewModel<MenuViewModel>(); firing when on large screens by altering the method calls from the view.
Many differences/Structural differences
If they share the same business logic but have very different UI requirements and you want to keep large screen code separate. Then I would suggest sharing the ViewModels but creating two separate Activites and layouts to handle the UI presentation. Using this method requires a bit more setup as you have to override some default MvvmCross behaviors as by default you can not register multiple Activities/Fragments to the same ViewModel. Overriding the MvxViewModelViewTypeFinder view lookup FindTypeOrNull you can intercept the lookup and filter types base on naming conventions. For example all large screen views end with "Tablet". Using the is_large_screen bool you can flag which views to register.
I'm developing a custom table component for very large and very custom content. Therefore I decided not to go with TableView, but start from scratch (i.e. Control). I adopted the idea of the VirtualFlow to create and manage only the visible part of the table and reuse cells that have become invisible. However I needed virtual rows and columns.
My CustomVirtualFlow implements layoutChildren(). From the component's size and scrollbar positions I know which cells are visible. If necessary, I add cells to the VirtualFlow. I then update the content and css pseudo class states (selected, focused, ...).
This works almost fine ... currently, my only problem is that the css styles are sometimes lagging: newly created cells are shown with e.g. wrong backgrounds for a moment and then get correcteted with the next pulse.
My explanation for this is that JavaFX performs layout in two passes:
first a css pass and secondly the layout pass that calls layoutChildren().
The css of newly added children (during layoutChildren) is therefore not processes correctly.
I tried to call applyCss() directly, which helps, but seems to do too much because it takes a lot of time.
My question is:
How is the correct way to add nodes during layout, i.e. if the size of the component makes it neccessary to use further nodes?
If it is not during layoutChildren(), where else should I do it?
i am new to GWT and GWTP and the question sounds stupid.. Can I make an abstract PresenterWidget or similiar?
Like in normal Java extending the "class" and reuse / extend the logic. But not only the class, the whole thing of View and Presenter. I try to explain my initial situation and maybe you have another idea.
The image hopefully helps to explain it. The "Main-Tab" and every other tab consists of a collection of views which have the same base structure and the same logic.
the base structure consists of
border around EVERYTHING
an image (the wwitch)
a title
a textarea
a PresenterWidget which is added to a contentSlot of the parent (the menu left)
and below the base are view specific components like buttons, text or any other widget. So a main part of the view with logic is repeading. If the switch is "toggled" the view is hidden (the textarea and any childs / view specific components) like the lowest view in the picture. Furthermore the PresenterWidget left changes the color.
The logic is working, but now I am searching a proper way to solve this without repeading code and the possibility to add child elements which are hidden as well by toggling the switch. Can I add to a PresenterWidget child widgets and define where there should be added? like: Even if this is possible, it feels a bit inconvenient.
Thanks in advance.
I just want to post the solution:
I have now a simple Composite (KPICommonView) for the switch, title and the description. It got another FlowPanel below the description, where the specific components will be added later. For this the Composite implements "HasWidgets" and overrides the "add(Widget w)"-method which is called by UiBinder if the Widget is added and has child elements.
<own:KPICommonView title="First Header" description="I am a happy description :)" anchorToken="{nameAnchors.getFirst}">
<g:Label>child component</g:Label>
</own:KPICommonView>
I am not sure if I do a PresenterWidget for every segment and every PresenterWidget has one of the KPICommonView added, or if I do one normal Presenter which adds more than one of the CommonViews.
The CommonView furhter creates the PresenterWidget for the menu item on the side. It gets the attributes from the constructor (anchorToken, title) and adds it to the slot (which happens ugly, because the View has hard coded the parent saved to call "addInSlot()". The repeading code for the switch is handled by the KPICommonView.
Background/Context:
I have a HBox as a parent and many child Nodes (Buttons, TextFields, Labels…). The HBox is a child of other container (BorderPane/VBox/Grid)
My questions:
How do I dynamically remove/exclude the parent (HBox) and all its children from layout?
I am looking for some three-state property on Node (like in Microsoft WPF):
Visible – visible and participate in layout
Collapsed – is not visible and do not participate in layout (applies to its children as well)
Hidden – is not visible but participate in layout
http://msdn.microsoft.com/en-us/library/ms590101.aspx
What options does JavaFX offer?
My solutions so far:
hBox.setManaged(false);
this work only for HBox, its children are still present
root.getChildren().remove(hBoxTop);
root.getChildren().add(hBoxTop);
Well, this looks like it could work.., but for example in case of root being BorderPane, once I remove/add and remove the HBox, the space after it remains unused. I already tried requestLayout() but id does not force thr rrot to fill it. Am I missing something? Is it correct approach to this problem?
Edited:
Well, I got this working.
Dynamically removing and adding for this specific case can be achieved by:
Remove:
root.setTop(null);
Add:
root.setTop(hBoxTop);
When I did not call setTop(null) on removal, BorderPane still reserved space for HBox (even after removal from its children).
IMHO: it is not very good model as it is parent-container specific. For example if I change, BorderPane to VBox a I had to change these methods as well. For VBox, remove/add on children collection works but I need to remember index so that HBox appears at same place after calling add.
Using root.setTop(null) is not a good idea because as you say it's specific to BorderPane.
I think the best solution is to use:
root.getChildren().remove(yourPane);
And use layout methods to place your other childrens as you want.
But maybe you should not use a BorderPane in the first place with the behaviors you want in your application.
Notice you can also do root.getChildren().clear() to remove all component and add it again to your layout but differently.