Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Eguis Ids are awesome, but sometimes it's a pain to figure out where a particular Id is coming from. This is an experiment at improving the situation by requiring the Id's source to implemnt
Debug
, storing the Debug representation as a string and the Ids optional parent in a global map, and showing the additional info it in the Debug implementation. Since most Ids are derived from a string this works really well:I also plan on adding a
Id::ui
that always shows the source and parent and more info on hover (the parents parent and maybe it could also look for widget rects with the Id and higlight those).Since the String only has to be created once for each unique Id this doesn't seem to have a huge performance impact, so I feel we can always enable this in debug builds.
The downside is of course that creating an Id from something now requires that thing to implement debug, but I don't think it would be a huge problem in practise. We could also add a
Id::new_without_debug_info()
that just requires the Hash trait.Also, the current Ui auto ids don't work well with this since they just implement an u64, but I'm sure there is a nice way to make that work.