Don't mind this @lwiklendt, but is there a reason we shouldn't just expose an &Style in the UI? This does add some maintenance burden onto the repo

I don't understand myself why originally &Style wasn't exposed. I think maybe @Gekkio wrote the clone version Ui::clone_style(&self) -> Style but I don't know how to get to the "0.1-dev" branch to see if there's a reason given. I agree if there are no problems, a Ui::style(&self) -> &Style would certainly be preferable.

Okay, I have some answers for you on why it's set up the way it is -- effectively, we violate memory safety if we give an &Style.

I created this simple program:

        let style = ui.style();
        let _t = ui.push_style_var(imgui::StyleVar::Alpha(0.2));

        let new_style = ui.style();

        println!(
            "equals, {}\n{:?}\n{:?}",
            style == new_style,
            style,
            new_style
        );

    // in ui...
    pub fn style(&self) -> &crate::Style {
        self.ctx.style()
    }

My expectation was that this would yield true and alpha in the style struct would be set to 1.0, the global default. Unfortunately, it yielded true, but with alpha at 0.2. This means that we held the immutable pointer to the C++ style struct in style while ImGui was mutating it when we called push_style_var. Obviously, we can't do, since the compiler will mess with this tremendously with optimizations it believes to be sound.

I think we have three options:

1. accept this PR with the negative side effects referenced
2. change the signature of style to &mut self, and yet return an &crate::Style (imgui's docs are explicit that we should not write to this data after calling NewFrame -- I assume push_style_var also does other work in addition to writing to this struct). This is kind of funky, since really push style var should be marked as mutable. I'd like to more to eventually have the ui methods use &mut self at some point, but our drop token method makes this complex.
3. We can use a getter function that takes StyleVar and match on that -- it already corresponds (I believe) to each field in the style struct, so that gives us a compile time warning as we update imgui.
4. give access to a raw ptr with some scare quotes in a safety doc. This can be accepted in addition to others.

What do you think?

I like 2, but I suspect it could require massive changes to peoples codebase to use. 3 and 4 might be the best option. Unfortunately, IIRC the style can be a number of different types, which... complicates things.

In the spirit of 3, there could be a Ui::get_style_var(&self, style_var: &mut StyleVar) where you supply (with dummy data) the variant you want to retrieve which gets filled with the correct data. It's probably not very "rusty" but it is kind of "imgui-y" considering functions like Ui::checkbox(&self, label: impl AsRef<str>, value: &mut bool) -> bool that take a mutable reference, albeit not with dummy data.

Although not all Style fields are represented by StyleVar. From imgui.h "The enum only refers to fields of ImGuiStyle which makes sense to be pushed/popped inside UI code". For example, Style::color_button_position is not represented in StyleVar.

Although not all Style fields are represented by StyleVar. From imgui.h "The enum only refers to fields of ImGuiStyle which makes sense to be pushed/popped inside UI code". For example, Style::color_button_position is not represented in StyleVar.

I think that pretty much kills option 3.

I like 2, but I suspect it could require massive changes to peoples codebase to use. 3 and 4 might be the best option. Unfortunately, IIRC the style can be a number of different types, which... complicates things.

I suspect this is all correct -- I mostly pass around &Ui<'_> in my app, which just prevents this mutable thing from working.

I think a larger conversation about mutability in the codebase will have to wait, but for now, I'm in favor of accepting the PR as is with the addition of 4 (we will likely forget to update these functions as the style struct changes at some point, which we should endeavor to not do, but having the emergency escape of 4 will be useful).

@lwiklendt would you mind adding that option 4? should return a *const Style with safety docs indicating that it will never be non-null but that it may be mutated by dear imgui (and should never be recast to a *mut and mutated through). See here if you want to copy some rhetoric: https://github.com/ocornut/imgui/blob/master/imgui.h#L301

A better option might be an unsafe fn that returns a &Style that you arent allowed to hold across other calls into imgui, since it may be mutated. That's easier to document, at least.

left one comment, once that's resolved, good to merge. Thank you and apologies that you ran into hotel order issue of mutability of the Ui object. I have some ideas but wow they;'d be a lot of breaking changes

Thank you!