v0.7.0
v0.7.0
-
Upgrade to Dear ImGui v1.80. (Note that the new table functionality is not yet supported, however)
-
Ui::key_index()
is now called internally when needed, and the variousis_key_foo
now take aKey
directly: #416is_key_down
,is_key_pressed
,is_key_released
andkey_pressed_amount
now take aKey
instead ofu32
(breaking).key_index
is no longer public (breaking). If you need access to the key map, it can be accessed asui.io().key_map[key]
(If you need to do this, file a bug, since I'm open to exposing this if there's actually a use case).
-
winit
0.23/0.24 handling has been (hopefully) fixed: #420 (breaking, see also #412).imgui-winit-support
'swinit-23
feature no longer supportswinit
version0.24
(this caused an unintentional semver breakage in theimgui-winit-support
crate before, unfortunately).imgui-winit-support
has a newwinit-24
feature for 0.24 support.- By default
imgui-winit-support
feature now enableswinit-24
, and notwinit-23
(by default it will always enable the latest).
-
The
imgui
crate no longer depends ongfx
orglium
directly: #420 (breaking, related to the previous change).- That is, the
gfx
andglium
features are removed to reduce version compatibility issues going forward.- This only matters if you manually implement
gfx
orglium
renderers without using theimgui-glium-renderer
orimgui-gfx-renderer
crates. - In the (somewhat unlikely) case you were relying on these this, you should define your own vertex type that's layout-compatible with
imgui::DrawVert
, and replace calls toimgui::DrawList::vtx_buffer()
withimgui::DrawList::transmute_vtx_buffer::<MyDrawVert>()
. You can seeimgui_glium_renderer::GliumDrawVert
andimgui_gfx_renderer::GfxDrawVert
types respectively for examples of this, if needed, but it should be straightforward enough if you're already implementing a renderer from scratch.
- This only matters if you manually implement
- This is admittedly less convenient, but avoids depending on any specific version of
gfx
orglium
in the coreimgui
crate, which will ease maintenance and reduce unintentional breakage in the future.
- That is, the
-
Non-window DrawList support has been fixed/improved: #414
WindowDrawList
has been renamed toDrawListMut
, to reflect that it may refer to other kinds of draw lists, and is mutable, unlikeimgui::DrawList
(breaking).Ui::get_background_draw_list()
has been fixed when used outside of a window context, and now has an example.Ui::get_foreground_draw_list()
has been added, analogous toUi::get_background_draw_list()
.
-
Added drag drop support, with a safe and an unsafe variant: #428
DragDropSource
allows users to create a dragdrop payload which is either empty, of'static + Copy
data,
orunsafe
, allowing for theoretically arbitrary payloads.DragDropTarget
allows users to accept any of the above payloads.- Extensive documentation has been made on all of these features, hopefully as a target for future features.
-
ImColor
(which is a wrapper aroundu32
) has been renamed toImColor32
in order to avoid confusion with theImColor
type from the Dear ImGui C++ code (which is a wrapper aroundImVec4
). In the future anImColor
type which maps more closely to the C++ one will be added.- Additionally, a number of constructor and accessor methods have been added to it
ImColor
, which areconst fn
where possible.
- Additionally, a number of constructor and accessor methods have been added to it
-
The
im_str!
macro can now be used inconst
contexts (when theformat!
version is not used). -
im_str!
now verifies that the parameter has no interior nuls at compile time. This can be avoided to get the old (truncating) behavior by forcing it to use theformat!
-like version, e.g.im_str!("for_some_reason_this_should_be_truncated\0 there {}", "")
.- This is not recommended, and is probably not useful.
-
Many functions are now
const fn
. -
A large number of small functions are now
#[inline]
, but many still aren't, so you probably will want to build with LTO for release builds if you useimgui
heavily. -
The
io.config_windows_memory_compact_timer
flag has been renamed toio.config_memory_compact_timer
. This follows the similar rename in the C++ ImGui, and was done because it no longer only applies to window memory usage. -
The variants of
ColorEditInputMode
andColorEditDisplayMode
have been renamed to be CamelCase instead of upper case (e.g.ColorEditFooMode::RGB
=>ColorEditFooMode::Rgb
).- However, this change is probably not breaking (in practice if not in theory) because const aliases using the old names are provided.