How can the behavior demonstrated here https://dojo.telerik.com/#zdravkov/owIqIlOF be redone in kendo/angular?
Specifically, how can I create a dropdowntree in angular where the categories (furniture and decor) are not selectable, but are expandable, and the child elements (tables & chairs, sofas, occasional furniture, bed linen, curtains & blinds, carpets) are selectable.
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.
Because I'm unsatisfied with the styling of fltk's built in Scroll group, I would like to create my own scroll group component , with similar functionality. Reading over the source code for FL_Scroll, I
gather that the process of "masking out" unneeded parts of the scroll groups children involves using fltk's damage functionality. I'm finding widget damage a difficult concept to understand. It seems like it relates to the way widgets are drawn, but I don't understand how it can be used to selectively draw parts of a widget.
Based on the fltk-rs docs for WidgetExt::set_damage() and WidgetExt::damage(), it seems like damaged is some kind of on/off state, like set_resizeable().
Yet in the FLTK docs I see this definition:
When redrawing your widgets you should look at the damage bits to see what parts of your widget need redrawing.
The handle() method can then set individual damage bits to limit the amount of drawing that needs to be done:
MyClass::handle(int event) {
...
if (change_to_part1) damage(1);
if (change_to_part2) damage(2);
if (change_to_part3) damage(4);
}
MyClass::draw() {
if (damage() & fltk::DAMAGE_ALL) {
... draw frame/box and other static stuff ...
}
if (damage() & (fltk::DAMAGE_ALL | 1)) draw_part1();
if (damage() & (fltk::DAMAGE_ALL | 2)) draw_part2();
if (damage() & (fltk::DAMAGE_ALL | 4)) draw_part3();
}
This description makes it seem like widget damage is referring to some kind of array of byte data about the widgets. I'm guessing for the scroll group,
you just want to draw the byte data within the scroll group's area. But where is this byte data stored? How can one access it? What does damage have to do with this data?
Contentful has a notion of "Links" which can be to many objects or one. However I can't find a way to model the reverse relationship without doubling the work (i.e. specify the children AND parent of each object).
I would like to use Contentful to power a simple navigation like so:
Menu Item 1
Sub menu item 1
Sub menu item 2
Sub menu item 3
Menu Item 2
Sub menu item 4
Sub menu item 5
Sub menu item 6
-- Sub sub menu item 1
Where the links might look like /<parent.slug>/<child.slug>/<child.slug>/
I could find the page entry to render by traversing up the parent relationships to ensure I get a page with a slug, and a parent with a specific slug.
However, It's hard to render out child menu items without resorting to multiple API calls unless you include a "children" field in the object - which is prone to error and inconsistency.
Yes we had this same issue. We have a Page model, with a refLink called 'parentPage'. Our middleware makes 1 call to CF to get ALL pages and builds a site tree model in memory.
From this model we have methods to get children, and get URL slug.
If your items only has a child relationship you can leverage the includes concept. Simply fetch the furthest down child item and set the includes parameter to a high enough value (10 is max) and Contentfuls API will include all referenced content in a single API call.
You can read more about includes here: https://www.contentful.com/developers/docs/references/content-delivery-api/#/reference/links
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?
Still working on learning here ... I'm trying to make an application window (stage) into which I can call child windows. The parent naturally comes with minimize, maximize and close (x) buttons, but when I add a child window I can't move or resize the child, and it does not have the standard three buttons.
Here's code I've been toying with:
// Stage ventasStage = new Stage(); // originally the child was stand alone and had the standard 3 buttons
AnchorPane ventas = (AnchorPane) FXMLLoader.load(Punto_de_Venta.class.getResource("VentasGUI.fxml"));
// Scene ventasScene = new Scene(ventas); //"stage" and "scene" removed to add "getChildren"
home.getChildren().add(ventas);
The getChildren gets my new window to be part of the parent scene, but I cannot get the 3 standard buttons. I assume the buttons are added to a Stage and NOT to an AnchorPane (which is what getChildren is getting here) but getChildren can't be used with a Stage, right? So how do I make a parent with interchangeable children where each child is moveable, resizable and has the standard three buttons (minimize, maximize and close)?
Three buttons correspond to a standart Window (it is provided by OS), and it is Stage. Scene - is an object, which corresponds to scene graph and is a propeerty of stage. So use stage.setScene(..) to set Scene to Stage. Stene has a root node (usually, some kind of layout). And it seems for me, that you should use Scene.setRoot(...) method.
BTW, about Stage: you can use stage.init...() to use different decoration schemas, and different types of modality.