Window::new -> Ui::window attempt 2 #537
Conversation
Mainly to try and clarify difference between Once/FirstUseEver
- ui.window(...).build() versus ui.window.begin() - ui.child_window(...)
There was a problem hiding this comment.
ah, just that one child window change with the id stack, and it's good to go! Sorry about all the annoying changes -- your meticulous examples and documentation just makes everything so perfect that I hate to request specific changes. I think if we lose that Id support, though, we'll be breaking some code that...somehow might rely on it.
I think I'll do an Id pass after this PR is accepted and remove all the Into<Id> bounds to just be Id, since Id is weird and asking users to make it themselves seems appropriate
| @@ -0,0 +1,67 @@ | |||
| mod support; | |||
There was a problem hiding this comment.
should we show off using imgui::Window::new? I think probably no, yeah?
There was a problem hiding this comment.
Might as well mention it as long as its available, even if just in a "probably don't use this" way
| @@ -0,0 +1,45 @@ | |||
| mod support; | |||
There was a problem hiding this comment.
Hahah, love that you made an example out of this. Thanks so much!
| .build(|| { | ||
| ui.text("Works!"); | ||
| for it in &items { | ||
| let _label_id = ui.push_id(it); |
There was a problem hiding this comment.
Hm, this usage suggests to me we should consider making the result of push_id deref into ui, so that you can do let ui = ui.push_id(...); (which avoids the footguns of let _ = ui.push_id(...) or forcing you to come up with a dummy name).
(This isn't related to the PR so much as a possible improved API.)
There was a problem hiding this comment.
Not only do I agree with that, I have been working on EXACTLY this change to the entire library.
this is the sort of thing that would be required to have proper mutability support for Ui (ie, some methods will take &mut self and others will take &self). For example, it occured to me that if the drop token for the table's api was also where you access all of the table's methods, then we solve #524 at the type level.
There are issues and i'm not sure we'll get that complex to start with, but I'm in total agreement here on that idea
Like #521 without me deleting useful things
..and so I tangentially added a bunch of examples of using
push_idtoo