Open mitchmindtree opened 7 years ago
What specific restrictions would apply to this? Would you still be able to set all the different attributes to the widgets? I haven't looked too closely at conrod's core, but the main advantages to this that I can see are:
Would this make the id list macro syntax obsolete?
Would you still be able to set all the different attributes to the widgets?
This would specifically be for graphics primitives and you'd only be able to specify attributes related to the graphics for that primitive (i.e. position, size, color, etc).
Would this make the id list macro syntax obsolete?
For many cases it would, but it would still be necessary for instantiating a dynamic number of non-graphics-primitive widgets.
It sounds like you have something more general in mind, which could also be useful! I've considered adding something like a Group
widget, where all it does is generate a number of Id
s that you specify and provide them in a iterator type widget event, something like
for id in Group::new(20).set(BUTTONS, ui) {
// instantiate each button with unique position, etc
}
I haven't got around to it as I wasn't sure if it would be worth it considering this would mean Group
would need a place within the widget_graph
(to store and re-use the Ids), whereas widget::id::List
does not and isn't too tricky to use. However, looking at that example, it does look like it could be nice to have as a more ergonomic option. Might be worth opening another issue for this.
I also have some other ideas for reducing the size of the conrod::graph::Container
(this is how widget's are stored within the widget_graph
). At the moment, the Container
stores a lot of redundant information for most widgets, including:
kid_area
upon which to place child widgets (that's different from its regular Rect
).whether or not the widget should crop its children widgets
I'd like to remove all of these fields from the graph::Container
in favour of storing fields like
floating: HashSet<widget::Id>,
scroll_x: HashMap<widget::Id, scroll::State<X>>,
scroll_y: HashMap<widget::Id, scroll::State<Y>>,
kid_area: HashMap<widget::Id, Rect>,
crop_kids: HashSet<widget::Id>,
within the Ui
. This way we only pay space for those that are scrollable/floating/cropping and we can remove those fields from the Container
. Anyways, this is probably also better as a separate issue!
So I have actually done this for both a list and a keypad.
While tracking ids, labels and button click action wasn't the easiest thing to deal with (Excel and Copy/Paste works wonders), the hardest this was positioning. I abused the down_from()
and managed to get everything looking nice.
The advantage I had was that everything is static and can be somewhat hard coded. Implementing the list and widgets 'on the fly' is not something that I would want to do at the moment.
At the moment, instantiating graphics primitives like
Rectangle
orLine
requires that each has its own unique slot within thewidget_graph
, and in turn requires they have their ownwidget::Id
s and other associated widget information. This is fine and useful for most cases, however can potentially cause trouble when a user requires instantiating thousands or more of them as discussed here. In cases like this, it would be much more efficient to allow the user to instantiate a single widget that could represent a whole list of graphics primitives.I can picture this widget being something like
Batch<T>
whereT
is some graphics primitive.Each primitive in the list would then be returned as
render::Primitive
s when drawing theUi
so that they can be rendered/optimised along with the rest of theUi
's graphics.cc @Boscop