Oh I did try and make this backwards compatible, but I couldn't see a nice way of doing this

Problem being:

1. Old code did: imgui::Window::new("Example").begin(ui) (or build)
2. New code ui.window("Example") returns imgui::Window, so .begin() (or build) must take ui arg

Only solutions to that I can think of are either:

1. Different named methods like ui.window("Example").begin2() (but couldn't think of a non-terrible name)
2. ui.window returns a different type (but that would mean duplicating all the methods on imgui::Window)

This is a good PR and I like this change. However, I think we should hold off till 0.8.0 is released. It does break code, and just going through a large work project and adapting it to the main branch took me about 2 hours. the vast majority of that was fixing im_str calls, but still, I think limiting that at least somewhat for now would be appreciated.

I'd like 0.9.0 to be virtually entirely changes like this (and I'd also like us to experiment a bit, maybe using begin_window and begin_window_with(name, big_data_blob_instead_of_params)).

What do you think? If you think I'm being overly cautious here, that'd be understandable

Yep makes sense! 0.8 already looks like it has enough excitement for one release 🥳

rebase and let's do it?

Done 🏃 (well merged instead of rebased as there was a bunch of conflicts which were easier to deal with that way)

The new table bindings use the Id type which is now otherwise entirely unused. I've not used the table API at all, so I couldn't work out what the user_id does or how it would be used, so I've currently just shoved the definition of Id inside tables.rs and left it as is.. but feel like it could probably be handled differently?

Yeah user_id basically let's you use a second, presumably cheap integer, user id for each column of your table. That shows up later in Sorting Operations. Possibly if the table is made completely dynamically, it could be your only way of identifying each column.

The Id struct is used in push_id. Why'd that get changed in this PR? I think it's not well implemented (I think as a general rule, doing Into<MyOwnType> in any crate is a bad idea), but I think the functionality is useful.

I use its functionality myself, for example, in various iterators where I'm generating label names dynamically. For example:

let my_values = ["hello", "hello", "goodbye"];

for (i, v) in my_values.iter().enumerate() {
    // just doing this here will bork, since we'll have two labels of "hello"
    // ui.button(v);

   // this fella works, but allocates a whole new string per button. wasteful
   // ui.button(format!("{}##{}", v, i));

   let t = ui.push_id(i);
   ui.button(v); // this guy works now, because we've incremented the ID stack, and imgui actually cares about the ENTIRE stack state, not just the current id
   drop(t);
}

so I'd not want to accept changing push_id to not accept integers, which are very useful

Ahhh I see! I couldn't see any uses of push_id in the repo and I missed the Into<Id> for integer as a way of actually using Id as a non-string (and I'd only used push_id in cases where I could do ui.push_id(an_existing_str), but makes perfect sense to accept an integer also)

I think I'll reopen the PR from a new branch with the ui.window changes reapplied (and maybe include some better docs for push_id instead of deleting it 😅 )

Created #537