Auto-assign UIID to `<widget_name>::draw` functions. about conrod HOT 11 CLOSED

OK after some helpful discussion on IRC it is apparent that this is very possible using procedural macros! I'm going to do some research and have a go at implementing this tonight.

from conrod.

So this is proving to be trickier than I thought!

My original idea was to create a macro via a syntax extension that would statically create a unique u64 in every instance that it is expanded, however this would still prove to be an issue when calling widget::draw in any kind of loop. The macro would have to be aware of the loop range, which renders the idea of statically assigning the UIIDs useless as the range length may often change at runtime.

For the moment, I don't have any ideas on how to elegantly tackle this - for now I guess we'll leave it up to the user to make sure each given UIID is unique.

In the mean-time I'm going to move ahead and have a go at creating some other widgets, but I will be giving this issue a lot of thought. Perhaps there's some other foundational way in which this can be addressed, but I can't think of it just yet. Any ideas would be super appreciated!

from conrod.

I was thinking of strings but then I figured it won't work out for loops. I guess generating a unique number is fine.

One idea is to provide an offset in the UID and all controls drawn in that "session" are relative to the offset. In many cases you might not need a global UID when a local one suffices.

Another idea is having an enum that provides a unique identifier one way or another, where you can choose to use a string slice or an UID depending on the use case.

from conrod.

How about taking uiid from the widget state vector?
If we don't delete widgets then next uiid is the vector length (with resize logic).
If we do then it's the first index where there is NoWidget.

from conrod.

Thanks @eklavya, but we can't do this due to the possibility of widgets being called conditionally at run-time (meaning the order of calling may change, and thus the wrong state would be retrieved)

from conrod.

Is that not a problem now because we hardcode uiids everywhere?
Isn't it possible to save uiid with the widget somehow?

from conrod.

Is that not a problem now

No as they are assigned statically, so when they request their state from the widget state vector, it's always the correct one.

Isn't it possible to save uiid with the widget somehow?

No because the widgets at call site are only functions.

I haven't yet been able to think of an efficient way of doing this at run-time and I'm not sure it's possible. I think perhaps it is possible to implement some kind of syntax extension as a helper, however to completely remove the need to think about uiids it would have to be aware of the entire control path including if/else, matches and bounds for loops (which are often determined dynamically). The uiid is a known quirk of the imgui approach, however if you come up with an efficient, simple solution that isn't an entirely retained approach, I want to know about it :)

from conrod.

In 90% of cases you want to display a list of controls, and the same goes for interfaces on mobile platforms. I think unique numbers is fine for this.

from conrod.

Closing.

from conrod.

Seeing how there is a desire for a widgets-id macro, I think it would be beneficial if the uiids were generated and given as tokens for each widget. It can be complex to properly associate widget ids with their corresponding widget manually, especially if widgets are dynamically created. Is it possible to store widget ids in the ui context, perhaps as a hashset?
I am considering a work-around but I'm not sure if it's possible to destroy a widget-id and mark for reuse, otherwise continually adding widget-ids during runtime will ultimately fail-- I assume; it's also overhead for the user, just as 'thinking about a coordinate system' would be.

Something like:

HashSet<(usize,u32)> //widget id, random::<u32>, though u64 might be better

This way instead of passing in uuid you would pass in the tuple, the actual uiid and its token to make unique. So when recycling a uiid, an outdated tuple is no longer appropriate and thus the uiid could safely be reused without checking against type_id equality. This would only work if a uiid could be recycled, which means it would have to be placed in a Vec for later popping. All of this would have to work within its own structure of registered tuples. I think this would make creating a widget-id macro simple since the uiid referenced would not have to be any specific order, additionally the macro could be called multiple times/separately.

// with ui context
let my_button_id = ui.register::<WidgetId>(); // returns tuple

This obviously requires changes in conrod, which I am not fully sure is possible. How is the widget cache checked for the ids currently? This possible solution may not be appropriate, but it's a start-- I think it's definitely worth reconsidering because the overhead of managing widget-ids is too high.

from conrod.

Closing this as conrod now supports both static and dynamically created IDs.

from conrod.