2023-05-31 16:19:06 +02:00
|
|
|
/* SPDX-FileCopyrightText: 2001-2002 NaN Holding BV. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup editorui
|
2011-02-21 07:25:24 +00:00
|
|
|
*/
|
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#pragma once
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
#include <functional>
|
2024-01-19 19:46:13 +01:00
|
|
|
#include <optional>
|
2023-08-04 22:15:25 -04:00
|
|
|
#include <string>
|
2023-07-25 16:22:31 +02:00
|
|
|
|
2013-09-01 15:01:15 +00:00
|
|
|
#include "BLI_compiler_attrs.h"
|
2023-09-12 14:47:46 +02:00
|
|
|
#include "BLI_string_ref.hh"
|
2023-06-26 06:05:18 +02:00
|
|
|
#include "BLI_string_utf8_symbols.h"
|
2013-05-28 19:35:26 +00:00
|
|
|
#include "BLI_sys_types.h" /* size_t */
|
2021-07-14 16:01:53 +02:00
|
|
|
#include "BLI_utildefines.h"
|
2025-02-11 16:59:42 +01:00
|
|
|
|
|
|
|
|
#include "DNA_userdef_types.h"
|
|
|
|
|
|
2023-08-05 02:57:52 +02:00
|
|
|
#include "UI_interface_icons.hh"
|
2025-02-11 16:59:42 +01:00
|
|
|
|
2023-08-04 23:11:22 +02:00
|
|
|
#include "WM_types.hh"
|
2009-07-21 01:26:17 +00:00
|
|
|
|
2024-07-05 17:09:40 +02:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Struct Declarations */
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
struct ARegion;
|
|
|
|
|
struct AutoComplete;
|
2021-01-05 23:04:51 +11:00
|
|
|
struct EnumPropertyItem;
|
2019-09-06 01:22:35 +02:00
|
|
|
struct FileSelectParams;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct ID;
|
|
|
|
|
struct IDProperty;
|
|
|
|
|
struct ImBuf;
|
|
|
|
|
struct Image;
|
|
|
|
|
struct ImageUser;
|
|
|
|
|
struct ListBase;
|
|
|
|
|
struct MTex;
|
2009-03-29 19:44:39 +00:00
|
|
|
struct Panel;
|
2009-04-11 01:52:27 +00:00
|
|
|
struct PanelType;
|
2023-08-04 22:15:25 -04:00
|
|
|
struct PanelCategoryDyn;
|
|
|
|
|
struct PanelCategoryStack;
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
struct PointerRNA;
|
|
|
|
|
struct PropertyRNA;
|
2008-12-29 13:38:08 +00:00
|
|
|
struct ReportList;
|
2020-04-14 18:46:13 +10:00
|
|
|
struct ResultBLF;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct bContext;
|
|
|
|
|
struct bContextStore;
|
|
|
|
|
struct bNode;
|
|
|
|
|
struct bNodeSocket;
|
|
|
|
|
struct bNodeTree;
|
|
|
|
|
struct bScreen;
|
2023-08-04 22:15:25 -04:00
|
|
|
struct MenuType;
|
2021-01-25 18:31:11 +11:00
|
|
|
struct rctf;
|
2009-04-09 18:11:18 +00:00
|
|
|
struct rcti;
|
2020-08-07 14:34:11 +02:00
|
|
|
struct uiButSearch;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiFontStyle;
|
This commit frees list ui items from their dependencies to Panel, and hence from all the limitations this implied (mostly, the "only one list per panel" one).
It introduces a new (py-extendable and registrable) RNA type, UIList (roughly similar to Panel one), which currently contains only "standard" list's scroll pos and size (but may be expended to include e.g. some filtering data, etc.). This now makes lists completely independent from Panels!
This UIList has a draw_item callback which allows to customize items' drawing from python, that all addons can now use. Incidentally, this also greatly simplifies the C code of this widget, as we do not code any "special case" here anymore!
To make all this work, other changes were also necessary:
* Now all buttons (uiBut struct) have a 'custom_data' void pointer, used currently to store the uiList struct associated with a given uiLayoutListBox.
* DynamicPaintSurface now exposes a new bool, use_color_preview (readonly), saying whether that surface has some 3D view preview data or not.
* UILayout class has now four new (static) functions, to get the actual icon of any RNA object (important e.g. with materials or textures), and to get an enum item's UI name, description and icon.
* UILayout's label() func now takes an optional 'icon_value' integer parameter, which if not zero will override the 'icon' one (mandatory to use "custom" icons as generated for material/texture/... previews).
Note: not sure whether we should add that one to all UILayout's prop funcs?
Note: will update addons using template list asap.
2012-12-28 09:20:16 +00:00
|
|
|
struct uiList;
|
2009-04-27 18:05:58 +00:00
|
|
|
struct uiStyle;
|
2009-07-03 11:46:46 +00:00
|
|
|
struct uiWidgetColors;
|
2014-07-21 12:02:05 +02:00
|
|
|
struct wmDrag;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct wmDropBox;
|
|
|
|
|
struct wmEvent;
|
2018-07-14 23:49:00 +02:00
|
|
|
struct wmGizmo;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct wmKeyConfig;
|
2018-05-20 22:34:18 +02:00
|
|
|
struct wmKeyMap;
|
2018-07-08 11:57:59 +02:00
|
|
|
struct wmKeyMapItem;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct wmMsgBus;
|
|
|
|
|
struct wmOperator;
|
|
|
|
|
struct wmOperatorType;
|
2022-06-16 11:29:20 +02:00
|
|
|
struct wmRegionListenerParams;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct wmWindow;
|
2024-02-21 14:23:17 +01:00
|
|
|
namespace blender::ed::asset {
|
|
|
|
|
struct AssetFilterSettings;
|
|
|
|
|
}
|
2024-03-08 09:16:00 -05:00
|
|
|
namespace blender::ui {
|
|
|
|
|
class AbstractView;
|
|
|
|
|
class AbstractViewItem;
|
|
|
|
|
} // namespace blender::ui
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiBlock;
|
|
|
|
|
struct uiBut;
|
|
|
|
|
struct uiButExtraOpIcon;
|
|
|
|
|
struct uiLayout;
|
|
|
|
|
struct uiPopupBlockHandle;
|
2023-09-15 21:06:30 +02:00
|
|
|
struct uiTooltipData;
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
|
|
|
|
/* Defines */
|
|
|
|
|
|
2023-01-11 13:39:13 +11:00
|
|
|
/**
|
|
|
|
|
* Character used for splitting labels (right align text after this character).
|
|
|
|
|
* Users should never see this character.
|
|
|
|
|
* Only applied when #UI_BUT_HAS_SEP_CHAR flag is enabled, see it's doc-string for details.
|
|
|
|
|
*/
|
2013-09-11 05:06:27 +00:00
|
|
|
#define UI_SEP_CHAR '|'
|
|
|
|
|
#define UI_SEP_CHAR_S "|"
|
|
|
|
|
|
2023-07-17 19:37:15 +02:00
|
|
|
/**
|
|
|
|
|
* Character used when value is indeterminate (multiple, unknown, unset).
|
|
|
|
|
*/
|
|
|
|
|
#define UI_VALUE_INDETERMINATE_CHAR BLI_STR_UTF8_EM_DASH
|
|
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* Separator for text in search menus (right pointing arrow).
|
|
|
|
|
* keep in sync with `string_search.cc`.
|
|
|
|
|
*/
|
2023-06-26 06:05:18 +02:00
|
|
|
#define UI_MENU_ARROW_SEP BLI_STR_UTF8_BLACK_RIGHT_POINTING_SMALL_TRIANGLE
|
2021-10-21 12:50:55 -05:00
|
|
|
|
2011-11-07 22:28:49 +00:00
|
|
|
/* names */
|
2012-05-12 20:39:39 +00:00
|
|
|
#define UI_MAX_DRAW_STR 400
|
|
|
|
|
#define UI_MAX_NAME_STR 128
|
2015-07-03 15:07:46 +02:00
|
|
|
#define UI_MAX_SHORTCUT_STR 64
|
2011-11-07 22:28:49 +00:00
|
|
|
|
2019-04-23 16:43:50 +10:00
|
|
|
/**
|
|
|
|
|
* For #ARegion.overlap regions, pass events though if they don't overlap
|
|
|
|
|
* the regions contents (the usable part of the #View2D and buttons).
|
|
|
|
|
*
|
2019-08-31 01:19:22 +10:00
|
|
|
* The margin is needed so it's not possible to accidentally click in between buttons.
|
2019-04-23 16:43:50 +10:00
|
|
|
*/
|
|
|
|
|
#define UI_REGION_OVERLAP_MARGIN (U.widget_unit / 3)
|
|
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Use for clamping popups within the screen. */
|
2013-02-07 02:03:31 +00:00
|
|
|
#define UI_SCREEN_MARGIN 10
|
|
|
|
|
|
2020-07-29 12:05:27 +10:00
|
|
|
/** #uiBlock.emboss and #uiBut.emboss */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eUIEmbossType {
|
2023-10-12 09:22:34 +11:00
|
|
|
/** Use widget style for drawing. */
|
|
|
|
|
UI_EMBOSS = 0,
|
|
|
|
|
/** Nothing, only icon and/or text */
|
|
|
|
|
UI_EMBOSS_NONE = 1,
|
|
|
|
|
/** Pull-down menu style */
|
|
|
|
|
UI_EMBOSS_PULLDOWN = 2,
|
|
|
|
|
/** Pie Menu */
|
2024-06-06 14:55:23 +02:00
|
|
|
UI_EMBOSS_PIE_MENU = 3,
|
2020-12-18 17:13:15 -06:00
|
|
|
/**
|
2021-01-05 13:38:48 +11:00
|
|
|
* The same as #UI_EMBOSS_NONE, unless the button has
|
2020-12-18 17:13:15 -06:00
|
|
|
* a coloring status like an animation state or red alert.
|
|
|
|
|
*/
|
|
|
|
|
UI_EMBOSS_NONE_OR_STATUS = 4,
|
2023-10-12 09:22:34 +11:00
|
|
|
/** For layout engine, use emboss from block. */
|
|
|
|
|
UI_EMBOSS_UNDEFINED = 255,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** #uiBlock::direction */
|
2014-11-09 21:20:40 +01:00
|
|
|
enum {
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_DIR_UP = 1 << 0,
|
|
|
|
|
UI_DIR_DOWN = 1 << 1,
|
|
|
|
|
UI_DIR_LEFT = 1 << 2,
|
|
|
|
|
UI_DIR_RIGHT = 1 << 3,
|
|
|
|
|
UI_DIR_CENTER_X = 1 << 4,
|
|
|
|
|
UI_DIR_CENTER_Y = 1 << 5,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_DIR_ALL = UI_DIR_UP | UI_DIR_DOWN | UI_DIR_LEFT | UI_DIR_RIGHT,
|
2014-11-09 21:20:40 +01:00
|
|
|
};
|
2013-06-25 10:30:07 +00:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** #uiBlock.flag (controls) */
|
|
|
|
|
enum {
|
|
|
|
|
UI_BLOCK_LOOP = 1 << 0,
|
2023-08-31 20:24:53 +02:00
|
|
|
UI_BLOCK_NUMSELECT = 1 << 1,
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Don't apply window clipping. */
|
2023-08-31 20:24:53 +02:00
|
|
|
UI_BLOCK_NO_WIN_CLIP = 1 << 2,
|
|
|
|
|
UI_BLOCK_CLIPBOTTOM = 1 << 3,
|
|
|
|
|
UI_BLOCK_CLIPTOP = 1 << 4,
|
|
|
|
|
UI_BLOCK_MOVEMOUSE_QUIT = 1 << 5,
|
|
|
|
|
UI_BLOCK_KEEP_OPEN = 1 << 6,
|
|
|
|
|
UI_BLOCK_POPUP = 1 << 7,
|
|
|
|
|
UI_BLOCK_OUT_1 = 1 << 8,
|
|
|
|
|
UI_BLOCK_SEARCH_MENU = 1 << 9,
|
|
|
|
|
UI_BLOCK_POPUP_MEMORY = 1 << 10,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Stop handling mouse events. */
|
2023-08-31 20:24:53 +02:00
|
|
|
UI_BLOCK_CLIP_EVENTS = 1 << 11,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/* #uiBlock::flags bits 14-17 are identical to #uiBut::drawflag bits. */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BLOCK_POPUP_HOLD = 1 << 18,
|
|
|
|
|
UI_BLOCK_LIST_ITEM = 1 << 19,
|
2024-06-06 14:55:23 +02:00
|
|
|
UI_BLOCK_PIE_MENU = 1 << 20,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BLOCK_POPOVER = 1 << 21,
|
|
|
|
|
UI_BLOCK_POPOVER_ONCE = 1 << 22,
|
2020-09-16 15:28:02 +10:00
|
|
|
/** Always show key-maps, even for non-menus. */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BLOCK_SHOW_SHORTCUT_ALWAYS = 1 << 23,
|
2022-03-24 17:40:59 +01:00
|
|
|
/** Don't show library override state for buttons in this block. */
|
|
|
|
|
UI_BLOCK_NO_DRAW_OVERRIDDEN_STATE = 1 << 24,
|
2020-09-15 11:25:49 -05:00
|
|
|
/** The block is only used during the search process and will not be drawn.
|
2020-09-16 15:28:02 +10:00
|
|
|
* Currently just for the case of a closed panel's sub-panel (and its sub-panels). */
|
2020-09-15 11:25:49 -05:00
|
|
|
UI_BLOCK_SEARCH_ONLY = 1 << 25,
|
2021-02-21 17:26:55 +01:00
|
|
|
/** Hack for quick setup (splash screen) to draw text centered. */
|
|
|
|
|
UI_BLOCK_QUICK_SETUP = 1 << 26,
|
2023-09-06 18:16:45 +02:00
|
|
|
/** Don't accelerator keys for the items in the block. */
|
|
|
|
|
UI_BLOCK_NO_ACCELERATOR_KEYS = 1 << 27,
|
2019-01-14 15:58:40 +11:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/** #uiPopupBlockHandle.menuretval */
|
|
|
|
|
enum {
|
|
|
|
|
/** Cancel all menus cascading. */
|
|
|
|
|
UI_RETURN_CANCEL = 1 << 0,
|
|
|
|
|
/** Choice made. */
|
|
|
|
|
UI_RETURN_OK = 1 << 1,
|
|
|
|
|
/** Left the menu. */
|
|
|
|
|
UI_RETURN_OUT = 1 << 2,
|
|
|
|
|
/** Let the parent handle this event. */
|
|
|
|
|
UI_RETURN_OUT_PARENT = 1 << 3,
|
|
|
|
|
/** Update the button that opened. */
|
|
|
|
|
UI_RETURN_UPDATE = 1 << 4,
|
|
|
|
|
/** Popup is ok to be handled. */
|
|
|
|
|
UI_RETURN_POPUP_OK = 1 << 5,
|
|
|
|
|
};
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2021-04-20 15:44:21 +10:00
|
|
|
/** #uiBut.flag general state flags. */
|
2013-11-21 14:43:08 +01:00
|
|
|
enum {
|
2022-05-13 15:55:11 +02:00
|
|
|
/* WARNING: the first 8 flags are internal (see #UI_SELECT definition). */
|
2023-07-26 15:23:24 +10:00
|
|
|
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_ICON_SUBMENU = 1 << 8,
|
|
|
|
|
UI_BUT_ICON_PREVIEW = 1 << 9,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_NODE_LINK = 1 << 10,
|
|
|
|
|
UI_BUT_NODE_ACTIVE = 1 << 11,
|
|
|
|
|
UI_BUT_DRAG_LOCK = 1 << 12,
|
2019-04-10 08:40:49 +02:00
|
|
|
/** Grayed out and un-editable. */
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_DISABLED = 1 << 13,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_ANIMATED = 1 << 14,
|
|
|
|
|
UI_BUT_ANIMATED_KEY = 1 << 15,
|
|
|
|
|
UI_BUT_DRIVEN = 1 << 16,
|
|
|
|
|
UI_BUT_REDALERT = 1 << 17,
|
2019-04-10 08:40:49 +02:00
|
|
|
/** Grayed out but still editable. */
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_INACTIVE = 1 << 18,
|
|
|
|
|
UI_BUT_LAST_ACTIVE = 1 << 19,
|
|
|
|
|
UI_BUT_UNDO = 1 << 20,
|
2022-05-20 16:27:08 +02:00
|
|
|
/* UNUSED = 1 << 21, */
|
2022-05-13 15:55:11 +02:00
|
|
|
UI_BUT_NO_UTF8 = 1 << 22,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-28 00:57:46 +11:00
|
|
|
/** For popups, pressing return activates this button, overriding the highlighted button.
|
|
|
|
|
* For non-popups this is just used as a display hint for the user to let them
|
|
|
|
|
* know the action which is activated when pressing return (file selector for eg). */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_ACTIVE_DEFAULT = 1 << 23,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** This but is "inside" a list item (currently used to change theme colors). */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_LIST_ITEM = 1 << 24,
|
2019-01-14 15:58:40 +11:00
|
|
|
/** edit this button as well as the active button (not just dragging) */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_DRAG_MULTI = 1 << 25,
|
2019-03-20 22:40:38 +11:00
|
|
|
/** Use for popups to start editing the button on initialization. */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_ACTIVATE_ON_INIT = 1 << 26,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-01-11 13:39:13 +11:00
|
|
|
/**
|
|
|
|
|
* #uiBut.str contains #UI_SEP_CHAR, used to show key-shortcuts right aligned.
|
|
|
|
|
*
|
|
|
|
|
* Since a label may contain #UI_SEP_CHAR, it's important to split on the last occurrence
|
|
|
|
|
* (meaning the right aligned text can't contain this character).
|
|
|
|
|
*/
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_HAS_SEP_CHAR = 1 << 27,
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Don't run updates while dragging (needed in rare cases). */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_UPDATE_DELAY = 1 << 28,
|
2022-05-05 10:55:51 +10:00
|
|
|
/** When widget is in text-edit mode, update value on each char stroke. */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_TEXTEDIT_UPDATE = 1 << 29,
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Show 'x' icon to clear/unlink value of text or search button. */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_VALUE_CLEAR = 1 << 30,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** RNA property of the button is overridden from linked reference data. */
|
2022-05-12 15:53:12 +02:00
|
|
|
UI_BUT_OVERRIDDEN = 1u << 31u,
|
2013-11-21 14:43:08 +01:00
|
|
|
};
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2023-09-06 18:16:45 +02:00
|
|
|
enum {
|
|
|
|
|
/**
|
|
|
|
|
* This is used when `UI_BUT_ACTIVATE_ON_INIT` is used, which is used to activate e.g. a search
|
|
|
|
|
* box as soon as a popup opens. Usually, the text in the search box is selected by default.
|
|
|
|
|
* However, sometimes this behavior is not desired, so it can be disabled with this flag.
|
|
|
|
|
*/
|
|
|
|
|
UI_BUT2_ACTIVATE_ON_INIT_NO_SELECT = 1 << 0,
|
UI: Support semi-modal text input while other UI stays interactive
Adds support for text buttons that capture text input, while the rest of the
UI stays interactive. This is useful for example for filter buttons in popups
that are used for searching. Current search popups are an ad-hoc implementation
that doesn't use the normal widget system (and thus are quite limited).
For the brush assets project this is important to allow quickly popping up the
brush asset shelf popup, immediately typing to search a brush, and activating
a brush with a single click (rather than having to confirm text input first).
All UI elements stay interactive with hover feedback, changing asset library
and catalogs is possible, tooltips and context menus can be opened, and any
text input is still sent to the search button.
Normal search popups already keep their search results interactive like this
during text input, but are too limited because they don't use our widget
system. For example custom layouts are not possible with them. With this
feature implemented, we could consider rewriting them to use the widget
system, removing the ad-hoc implementation.
Part of the brush assets project, see:
- https://projects.blender.org/blender/blender/issues/116337
- https://projects.blender.org/blender/blender/pulls/106303
Initially reviewed in:
https://projects.blender.org/blender/blender/pulls/122871
2024-07-06 12:22:16 +02:00
|
|
|
/**
|
|
|
|
|
* Force the button as active in a semi-modal state. For example, text buttons can continuously
|
|
|
|
|
* capture text input, while leaving the remaining UI interactive. Only supported well for text
|
|
|
|
|
* buttons currently.
|
|
|
|
|
*/
|
|
|
|
|
UI_BUT2_FORCE_SEMI_MODAL_ACTIVE = 1 << 1,
|
2023-09-06 18:16:45 +02:00
|
|
|
};
|
|
|
|
|
|
2023-02-20 11:51:16 +01:00
|
|
|
/** #uiBut.dragflag */
|
|
|
|
|
enum {
|
|
|
|
|
/** By default only the left part of a button triggers dragging. A questionable design to make
|
|
|
|
|
* the icon but not other parts of the button draggable. Set this flag so the entire button can
|
|
|
|
|
* be dragged. */
|
|
|
|
|
UI_BUT_DRAG_FULL_BUT = (1 << 0),
|
|
|
|
|
|
|
|
|
|
/* --- Internal flags. --- */
|
|
|
|
|
UI_BUT_DRAGPOIN_FREE = (1 << 1),
|
|
|
|
|
};
|
|
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Default font size for normal text. */
|
2021-11-13 09:39:18 -08:00
|
|
|
#define UI_DEFAULT_TEXT_POINTS 11.0f
|
2020-10-12 09:53:00 -07:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Larger size used for title text. */
|
2021-11-13 09:39:18 -08:00
|
|
|
#define UI_DEFAULT_TITLE_POINTS 11.0f
|
2020-10-12 09:53:00 -07:00
|
|
|
|
2024-07-25 19:12:41 +02:00
|
|
|
/** Size of tooltip text. */
|
|
|
|
|
#define UI_DEFAULT_TOOLTIP_POINTS 11.0f
|
|
|
|
|
|
2012-05-12 20:39:39 +00:00
|
|
|
#define UI_PANEL_WIDTH 340
|
|
|
|
|
#define UI_COMPACT_PANEL_WIDTH 160
|
2024-06-03 19:21:31 +02:00
|
|
|
#define UI_SIDEBAR_PANEL_WIDTH 280
|
2018-11-25 16:21:35 +01:00
|
|
|
#define UI_NAVIGATION_REGION_WIDTH UI_COMPACT_PANEL_WIDTH
|
2019-01-17 14:31:18 +01:00
|
|
|
#define UI_NARROW_NAVIGATION_REGION_WIDTH 100
|
2009-04-09 18:11:18 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** The width of one icon column of the Toolbar. */
|
2023-06-08 18:27:59 +02:00
|
|
|
#define UI_TOOLBAR_COLUMN (1.25f * ICON_DEFAULT_HEIGHT_TOOLBAR)
|
2023-07-26 15:23:24 +10:00
|
|
|
/** The space between the Toolbar and the area's edge. */
|
2023-06-08 18:27:59 +02:00
|
|
|
#define UI_TOOLBAR_MARGIN (0.5f * ICON_DEFAULT_HEIGHT_TOOLBAR)
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Total width of Toolbar showing one icon column. */
|
2023-06-08 18:27:59 +02:00
|
|
|
#define UI_TOOLBAR_WIDTH UI_TOOLBAR_MARGIN + UI_TOOLBAR_COLUMN
|
|
|
|
|
|
2014-01-04 13:54:39 -06:00
|
|
|
#define UI_PANEL_CATEGORY_MARGIN_WIDTH (U.widget_unit * 1.0f)
|
2013-12-17 03:21:55 +11:00
|
|
|
|
2021-11-25 16:53:44 +01:00
|
|
|
/* Both these margins should be ignored if the panel doesn't show a background (check
|
|
|
|
|
* #UI_panel_should_show_background()). */
|
UI: Visual style update to panels
Back in Blender 2.30, the GUI project brought panels into Blender among other important visual updates.
For the first time it was possible to move the wall of buttons around. Providing a clear separation
between sections (it even allowed the grouping of panels in tabs!)
During the 2.5 redesign, the separation between panels became a line on top of each panel, and panels received
theme settings for background and header colors. The default theme used the same color for both.
In 2.8 the background color of panels was different from headers in the default theme, so the separator
line was removed. While the separator line wasn't elegant (only on top, non-themeable, hard-coded emboss effect),
it provided a sort of separation between panels.
This patch solves the panels-separation by simply adding a margin space around them (not visible in default theme yet).
Even though the margin reduces the width of the working area slightly, it makes room for the upcoming always-visible scrollbars.
Other adjustments:
* Use arrow icon instead of triangle to collapse/expand
* Use rounded corners to match the rest of the UI (editor corners, nodes, etc).
{F10953929, size=full}
Margin on panels makes use of the `style->panelouter` property that hasn't been
used in a while. Also slight tweaks to `boxspace` and `templatespace` style properties so they
are multiples of 2 and operations on them round better.
There is technically no need to update the themes for them to work, so no theme changes are included in this patch.
{F10953931, size=full}
{F10953933, size=full}
{F10953934, size=full}
{F10954003, size=full}
----
A new theme setting under Style controls the roundness of all panels (added it to Style instead of ThemeSpace because I think controlling the panel roundness per editor is a bit overkill):
{F11091561, size=full, autoplay, loop}
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D12814
2021-10-17 18:22:53 +02:00
|
|
|
#define UI_PANEL_MARGIN_X (U.widget_unit * 0.4f)
|
2021-10-18 16:16:34 +02:00
|
|
|
#define UI_PANEL_MARGIN_Y (U.widget_unit * 0.1f)
|
2020-05-26 15:39:49 -04:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* #uiBut::drawflag, these flags should only affect how the button is drawn.
|
|
|
|
|
*
|
|
|
|
|
* \note currently, these flags *are not passed* to the widgets state() or draw() functions
|
|
|
|
|
* (except for the 'align' ones)!
|
2013-11-21 16:51:29 +01:00
|
|
|
*/
|
2013-11-21 14:43:08 +01:00
|
|
|
enum {
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Text and icon alignment (by default, they are centered). */
|
|
|
|
|
UI_BUT_TEXT_LEFT = 1 << 1,
|
|
|
|
|
UI_BUT_ICON_LEFT = 1 << 2,
|
|
|
|
|
UI_BUT_TEXT_RIGHT = 1 << 3,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Prevent the button to show any tool-tip. */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BUT_NO_TOOLTIP = 1 << 4,
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* Show a quick tool-tip label, that is, a short tool-tip that appears faster than the full one
|
|
|
|
|
* and only shows the label. After a short delay the full tool-tip is shown if any.
|
|
|
|
|
*/
|
2023-07-25 16:22:31 +02:00
|
|
|
UI_BUT_HAS_TOOLTIP_LABEL = 1 << 5,
|
UI: Better split layout support for checkboxes
Makes the following layout changes possible:
{F8473498} {F8473499} {F8473502}
The next commit will contain many layout changes to make good use of
these new possibilities. The result should be more consistent, easier to
read and should give a more organized impression. Additionally, it
should be possible to replace many sub-panels with compacter layouts.
Main changes:
* Checkboxes now respect the property split layouts
* Add support for row and column headers (i.e.
`uiLayout.column(heading="Foo")`, `uiLayout.row(heading="Bar")`). If the
first property added to this layout doesn't insert anything into the label
split column, the heading is inserted there. Otherwise, it's inserted as own
item.
* Add support for manually inserting decorators for an existing item
(`uiLayout.prop_decorator()`). That way layout creators can manually insert
this, which was the only way I saw to support property split layouts with a
checkbox before the actual property. {F8471883}
* Autogenerated layouts for operator properties look bad if there are only
checkboxes (which only use half the region width). So before creating the
layout, we iterate over visible properties and disable split layout if all
are booleans. I think this is fine, if needed we could also add layout hints
to operators.
* `uiTemplateOperatorPropertyButs()` now handles macros itself, the caller
used to be responsible for this. Code that didn't handle these so far never
used macros I think, so this change should be invisible.
* Remove manual property split layout from autogenerated operator properties
layout.
* Padding of checkboxes is tweaked to make their label visually more connected
to the checkboxes.
* Support split layout for menus (should work for `uiLayout.menu()`,
`.operator_menu_enum()`, `.prop_menu_enum()`, maybe more)
Maniphest Task: https://developer.blender.org/T65965
Differential Revision: https://developer.blender.org/D7427
Reviewed by: Brecht Van Lommel, William Reynish, Pablo Vazques
2020-04-17 16:40:25 +02:00
|
|
|
/** Do not add the usual horizontal padding for text drawing. */
|
2023-07-25 16:22:31 +02:00
|
|
|
UI_BUT_NO_TEXT_PADDING = 1 << 6,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-03 01:10:03 +11:00
|
|
|
/* Button align flag, for drawing groups together.
|
|
|
|
|
* Used in 'uiBlock.flag', take care! */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BUT_ALIGN_TOP = 1 << 14,
|
|
|
|
|
UI_BUT_ALIGN_LEFT = 1 << 15,
|
|
|
|
|
UI_BUT_ALIGN_RIGHT = 1 << 16,
|
|
|
|
|
UI_BUT_ALIGN_DOWN = 1 << 17,
|
|
|
|
|
UI_BUT_ALIGN = UI_BUT_ALIGN_TOP | UI_BUT_ALIGN_LEFT | UI_BUT_ALIGN_RIGHT | UI_BUT_ALIGN_DOWN,
|
2017-11-03 01:10:03 +11:00
|
|
|
/* end bits shared with 'uiBlock.flag' */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/**
|
|
|
|
|
* Warning - HACK!
|
|
|
|
|
* Needed for buttons which are not TOP/LEFT aligned,
|
|
|
|
|
* but have some top/left corner stitched to some other TOP/LEFT-aligned button,
|
2023-07-26 15:23:24 +10:00
|
|
|
* because of "corrective" hack in #widget_roundbox_set().
|
|
|
|
|
*/
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BUT_ALIGN_STITCH_TOP = 1 << 18,
|
|
|
|
|
UI_BUT_ALIGN_STITCH_LEFT = 1 << 19,
|
|
|
|
|
UI_BUT_ALIGN_ALL = UI_BUT_ALIGN | UI_BUT_ALIGN_STITCH_TOP | UI_BUT_ALIGN_STITCH_LEFT,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** This but is "inside" a box item (currently used to change theme colors). */
|
|
|
|
|
UI_BUT_BOX_ITEM = 1 << 20,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-10-25 18:36:27 +02:00
|
|
|
/** Mouse is hovering left part of number button */
|
|
|
|
|
UI_BUT_HOVER_LEFT = 1 << 21,
|
|
|
|
|
/** Mouse is hovering right part of number button */
|
|
|
|
|
UI_BUT_HOVER_RIGHT = 1 << 22,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Reverse order of consecutive off/on icons */
|
2021-06-15 18:53:32 +02:00
|
|
|
UI_BUT_ICON_REVERSE = 1 << 23,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Value is animated, but the current value differs from the animated one. */
|
2021-06-15 18:53:32 +02:00
|
|
|
UI_BUT_ANIMATED_CHANGED = 1 << 24,
|
2019-05-20 12:14:48 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Draw the checkbox buttons inverted. */
|
2021-06-15 18:53:32 +02:00
|
|
|
UI_BUT_CHECKBOX_INVERT = 1 << 25,
|
2023-07-17 19:37:15 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Drawn in a way that indicates that the state/value is unknown. */
|
2023-07-17 19:37:15 +02:00
|
|
|
UI_BUT_INDETERMINATE = 1 << 26,
|
2024-05-06 23:52:37 +02:00
|
|
|
|
|
|
|
|
/** Draw icon inverted to indicate a special state. */
|
|
|
|
|
UI_BUT_ICON_INVERT = 1 << 27,
|
2013-11-21 14:43:08 +01:00
|
|
|
};
|
2012-05-23 14:24:40 +00:00
|
|
|
|
2020-07-07 12:44:47 +10:00
|
|
|
/**
|
|
|
|
|
* Button types, bits stored in 1 value... and a short even!
|
|
|
|
|
* - bits 0-4: #uiBut.bitnr (0-31)
|
2012-03-03 16:31:46 +00:00
|
|
|
* - bits 5-7: pointer type
|
|
|
|
|
* - bit 8: for 'bit'
|
|
|
|
|
* - bit 9-15: button type (now 6 bits, 64 types)
|
2020-07-07 12:44:47 +10:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eButPointerType {
|
2023-02-03 16:12:14 +01:00
|
|
|
UI_BUT_POIN_NONE = 0,
|
|
|
|
|
|
2012-09-12 00:32:33 +00:00
|
|
|
UI_BUT_POIN_CHAR = 32,
|
|
|
|
|
UI_BUT_POIN_SHORT = 64,
|
|
|
|
|
UI_BUT_POIN_INT = 96,
|
|
|
|
|
UI_BUT_POIN_FLOAT = 128,
|
2021-06-26 21:35:18 +10:00
|
|
|
// UI_BUT_POIN_FUNCTION = 192, /* UNUSED */
|
|
|
|
|
UI_BUT_POIN_BIT = 256, /* OR'd with a bit index. */
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** \note requires `but->poin != NULL`. */
|
2012-09-12 00:32:33 +00:00
|
|
|
#define UI_BUT_POIN_TYPES (UI_BUT_POIN_FLOAT | UI_BUT_POIN_SHORT | UI_BUT_POIN_CHAR)
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* #uiBut::type
|
|
|
|
|
* OR'd with #eButPointerType when passing as an argument.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eButType {
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_BUT = 1 << 9,
|
|
|
|
|
UI_BTYPE_ROW = 2 << 9,
|
|
|
|
|
UI_BTYPE_TEXT = 3 << 9,
|
2020-09-16 15:28:02 +10:00
|
|
|
/** Drop-down list. */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_MENU = 4 << 9,
|
|
|
|
|
UI_BTYPE_BUT_MENU = 5 << 9,
|
|
|
|
|
/** number button */
|
|
|
|
|
UI_BTYPE_NUM = 6 << 9,
|
|
|
|
|
/** number slider */
|
|
|
|
|
UI_BTYPE_NUM_SLIDER = 7 << 9,
|
|
|
|
|
UI_BTYPE_TOGGLE = 8 << 9,
|
|
|
|
|
UI_BTYPE_TOGGLE_N = 9 << 9,
|
|
|
|
|
UI_BTYPE_ICON_TOGGLE = 10 << 9,
|
|
|
|
|
UI_BTYPE_ICON_TOGGLE_N = 11 << 9,
|
|
|
|
|
/** same as regular toggle, but no on/off state displayed */
|
|
|
|
|
UI_BTYPE_BUT_TOGGLE = 12 << 9,
|
|
|
|
|
/** similar to toggle, display a 'tick' */
|
|
|
|
|
UI_BTYPE_CHECKBOX = 13 << 9,
|
|
|
|
|
UI_BTYPE_CHECKBOX_N = 14 << 9,
|
|
|
|
|
UI_BTYPE_COLOR = 15 << 9,
|
|
|
|
|
UI_BTYPE_TAB = 16 << 9,
|
|
|
|
|
UI_BTYPE_POPOVER = 17 << 9,
|
|
|
|
|
UI_BTYPE_SCROLL = 18 << 9,
|
|
|
|
|
UI_BTYPE_BLOCK = 19 << 9,
|
|
|
|
|
UI_BTYPE_LABEL = 20 << 9,
|
|
|
|
|
UI_BTYPE_KEY_EVENT = 24 << 9,
|
|
|
|
|
UI_BTYPE_HSVCUBE = 26 << 9,
|
2022-09-07 12:52:05 +10:00
|
|
|
/** Menu (often used in headers), `*_MENU` with different draw-type. */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_PULLDOWN = 27 << 9,
|
|
|
|
|
UI_BTYPE_ROUNDBOX = 28 << 9,
|
|
|
|
|
UI_BTYPE_COLORBAND = 30 << 9,
|
|
|
|
|
/** sphere widget (used to input a unit-vector, aka normal) */
|
|
|
|
|
UI_BTYPE_UNITVEC = 31 << 9,
|
|
|
|
|
UI_BTYPE_CURVE = 32 << 9,
|
2019-11-20 16:12:32 -05:00
|
|
|
/** Profile editing widget */
|
|
|
|
|
UI_BTYPE_CURVEPROFILE = 33 << 9,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_LISTBOX = 36 << 9,
|
|
|
|
|
UI_BTYPE_LISTROW = 37 << 9,
|
|
|
|
|
UI_BTYPE_HSVCIRCLE = 38 << 9,
|
|
|
|
|
UI_BTYPE_TRACK_PREVIEW = 40 << 9,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Buttons with value >= #UI_BTYPE_SEARCH_MENU don't get undo pushes. */
|
|
|
|
|
UI_BTYPE_SEARCH_MENU = 41 << 9,
|
|
|
|
|
UI_BTYPE_EXTRA = 42 << 9,
|
2021-07-13 17:30:34 +02:00
|
|
|
/** A preview image (#PreviewImage), with text under it. Typically bigger than normal buttons and
|
|
|
|
|
* laid out in a grid, e.g. like the File Browser in thumbnail display mode. */
|
|
|
|
|
UI_BTYPE_PREVIEW_TILE = 43 << 9,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_HOTKEY_EVENT = 46 << 9,
|
|
|
|
|
/** Non-interactive image, used for splash screen */
|
|
|
|
|
UI_BTYPE_IMAGE = 47 << 9,
|
|
|
|
|
UI_BTYPE_HISTOGRAM = 48 << 9,
|
|
|
|
|
UI_BTYPE_WAVEFORM = 49 << 9,
|
|
|
|
|
UI_BTYPE_VECTORSCOPE = 50 << 9,
|
2023-07-12 13:15:39 +10:00
|
|
|
UI_BTYPE_PROGRESS = 51 << 9,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_NODE_SOCKET = 53 << 9,
|
|
|
|
|
UI_BTYPE_SEPR = 54 << 9,
|
|
|
|
|
UI_BTYPE_SEPR_LINE = 55 << 9,
|
|
|
|
|
/** Dynamically fill available space. */
|
|
|
|
|
UI_BTYPE_SEPR_SPACER = 56 << 9,
|
2023-01-20 15:19:32 +11:00
|
|
|
/** Resize handle (resize UI-list). */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_BTYPE_GRIP = 57 << 9,
|
2020-08-07 14:34:11 +02:00
|
|
|
UI_BTYPE_DECORATOR = 58 << 9,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** An item a view (see #ui::AbstractViewItem). */
|
UI: Port view item features to base class, merge view item button types
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
|
|
|
UI_BTYPE_VIEW_ITEM = 59 << 9,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2012-05-12 20:39:39 +00:00
|
|
|
|
|
|
|
|
#define BUTTYPE (63 << 9)
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/** Gradient types, for color picker #UI_BTYPE_HSVCUBE etc. */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eButGradientType {
|
2023-09-27 14:28:47 +10:00
|
|
|
UI_GRAD_NONE = -1,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_GRAD_SV = 0,
|
|
|
|
|
UI_GRAD_HV = 1,
|
|
|
|
|
UI_GRAD_HS = 2,
|
|
|
|
|
UI_GRAD_H = 3,
|
|
|
|
|
UI_GRAD_S = 4,
|
|
|
|
|
UI_GRAD_V = 5,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_GRAD_V_ALT = 9,
|
|
|
|
|
UI_GRAD_L_ALT = 10,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2010-01-21 00:00:45 +00:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Drawing
|
|
|
|
|
*
|
|
|
|
|
* Functions to draw various shapes, taking theme settings into account.
|
|
|
|
|
* Used for code that draws its own UI style elements. */
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_draw_roundbox_corner_set(int type);
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_draw_roundbox_aa(const rctf *rect, bool filled, float rad, const float color[4]);
|
|
|
|
|
void UI_draw_roundbox_4fv(const rctf *rect, bool filled, float rad, const float col[4]);
|
|
|
|
|
void UI_draw_roundbox_3ub_alpha(
|
|
|
|
|
const rctf *rect, bool filled, float rad, const unsigned char col[3], unsigned char alpha);
|
2021-01-25 18:31:11 +11:00
|
|
|
void UI_draw_roundbox_3fv_alpha(
|
2023-08-04 22:15:25 -04:00
|
|
|
const rctf *rect, bool filled, float rad, const float col[3], float alpha);
|
|
|
|
|
void UI_draw_roundbox_4fv_ex(const rctf *rect,
|
2021-01-23 13:10:07 -08:00
|
|
|
const float inner1[4],
|
|
|
|
|
const float inner2[4],
|
|
|
|
|
float shade_dir,
|
2021-01-25 18:02:55 +11:00
|
|
|
const float outline[4],
|
2021-01-23 13:10:07 -08:00
|
|
|
float outline_width,
|
|
|
|
|
float rad);
|
2017-04-06 19:15:26 -04:00
|
|
|
|
|
|
|
|
#if 0 /* unused */
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_draw_roundbox_corner_get();
|
2017-04-06 19:15:26 -04:00
|
|
|
#endif
|
|
|
|
|
|
2023-11-24 22:50:20 +01:00
|
|
|
void ui_draw_dropshadow(const rctf *rct, float radius, float width, float aspect, float alpha);
|
|
|
|
|
|
2017-02-06 16:54:26 +01:00
|
|
|
void UI_draw_text_underline(int pos_x, int pos_y, int len, int height, const float color[4]);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draw title and text safe areas.
|
|
|
|
|
*
|
|
|
|
|
* \note This function is to be used with the 2D dashed shader enabled.
|
|
|
|
|
*
|
|
|
|
|
* \param pos: is a #PRIM_FLOAT, 2, #GPU_FETCH_FLOAT vertex attribute.
|
2021-12-14 18:35:23 +11:00
|
|
|
* \param rect: The offsets for the view, not the zones.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
void UI_draw_safe_areas(uint pos,
|
2023-08-04 22:15:25 -04:00
|
|
|
const rctf *rect,
|
2015-01-19 16:30:35 +11:00
|
|
|
const float title_aspect[2],
|
|
|
|
|
const float action_aspect[2]);
|
|
|
|
|
|
2023-01-20 15:19:32 +11:00
|
|
|
/** State for scroll-drawing. */
|
2019-01-14 15:58:40 +11:00
|
|
|
enum {
|
|
|
|
|
UI_SCROLL_PRESSED = 1 << 0,
|
|
|
|
|
UI_SCROLL_ARROWS = 1 << 1,
|
|
|
|
|
};
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Function in use for buttons and for view2d sliders.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_draw_widget_scroll(uiWidgetColors *wcol, const rcti *rect, const rcti *slider, int state);
|
2009-07-03 10:54:39 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Shortening string helper.
|
|
|
|
|
*
|
|
|
|
|
* Cut off the middle of the text to fit into the given width.
|
|
|
|
|
*
|
|
|
|
|
* \note in case this middle clipping would just remove a few chars,
|
|
|
|
|
* it rather clips right, which is more readable.
|
|
|
|
|
*
|
2023-07-26 15:23:24 +10:00
|
|
|
* If `rpart_sep` is not null, the part of `str` starting to first occurrence of `rpart_sep`
|
2021-12-09 00:55:11 +11:00
|
|
|
* is preserved at all cost.
|
|
|
|
|
* Useful for strings with shortcuts
|
2023-07-26 15:23:24 +10:00
|
|
|
* (like `A Very Long Foo Bar Label For Menu Entry|Ctrl O' -> 'AVeryLong...MenuEntry|Ctrl O`).
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
float UI_text_clip_middle_ex(const uiFontStyle *fstyle,
|
2019-01-04 09:58:03 +11:00
|
|
|
char *str,
|
|
|
|
|
float okwidth,
|
2022-01-07 11:38:08 +11:00
|
|
|
float minwidth,
|
2022-01-12 12:49:36 +01:00
|
|
|
size_t max_len,
|
2022-01-07 11:38:08 +11:00
|
|
|
char rpart_sep);
|
2015-05-04 21:12:28 +02:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/**
|
2023-07-26 15:23:24 +10:00
|
|
|
* Callbacks.
|
2011-11-24 13:51:31 +00:00
|
|
|
*
|
2023-07-26 15:23:24 +10:00
|
|
|
* #UI_block_func_handle_set/ButmFunc are for handling events through a callback.
|
2011-11-24 13:51:31 +00:00
|
|
|
* HandleFunc gets the retval passed on, and ButmFunc gets a2. The latter is
|
|
|
|
|
* mostly for compatibility with older code.
|
|
|
|
|
*
|
2019-01-14 15:58:40 +11:00
|
|
|
* - #UI_but_func_complete_set is for tab completion.
|
2011-11-24 13:51:31 +00:00
|
|
|
*
|
2019-01-14 15:58:40 +11:00
|
|
|
* - #uiButSearchFunc is for name buttons, showing a popup with matches
|
2011-11-24 13:51:31 +00:00
|
|
|
*
|
2019-01-14 15:58:40 +11:00
|
|
|
* - #UI_block_func_set and UI_but_func_set are callbacks run when a button is used,
|
|
|
|
|
* in case events, operators or RNA are not sufficient to handle the button.
|
2011-11-24 13:51:31 +00:00
|
|
|
*
|
2019-01-14 15:58:40 +11:00
|
|
|
* - #UI_but_funcN_set will free the argument with MEM_freeN. */
|
2011-11-24 13:51:31 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiSearchItems;
|
2011-11-24 13:51:31 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiButHandleFunc = void (*)(bContext *C, void *arg1, void *arg2);
|
|
|
|
|
using uiButHandleRenameFunc = void (*)(bContext *C, void *arg, char *origstr);
|
|
|
|
|
using uiButHandleNFunc = void (*)(bContext *C, void *argN, void *arg2);
|
|
|
|
|
using uiButHandleHoldFunc = void (*)(bContext *C, ARegion *butregion, uiBut *but);
|
|
|
|
|
using uiButCompleteFunc = int (*)(bContext *C, char *str, void *arg);
|
2020-03-24 11:34:18 +11:00
|
|
|
|
2024-07-05 17:09:40 +02:00
|
|
|
/**
|
|
|
|
|
* Signatures of callbacks used to free or copy some 'owned' void pointer data (like e.g.
|
|
|
|
|
* #func_argN in #uiBut or #uiBlock).
|
|
|
|
|
*/
|
|
|
|
|
using uiButArgNFree = void (*)(void *argN);
|
|
|
|
|
using uiButArgNCopy = void *(*)(const void *argN);
|
|
|
|
|
|
2023-11-30 14:15:11 +11:00
|
|
|
/**
|
|
|
|
|
* Function to compare the identity of two buttons over redraws, to check if they represent the
|
|
|
|
|
* same data, and thus should be considered the same button over redraws.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiButIdentityCompareFunc = bool (*)(const uiBut *a, const uiBut *b);
|
2022-04-26 22:26:15 +02:00
|
|
|
|
2020-05-07 23:16:05 +10:00
|
|
|
/* Search types. */
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiButSearchCreateFn = ARegion *(*)(bContext *C, ARegion *butregion, uiButSearch *search_but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* `is_first` is typically used to ignore search filtering when the menu is first opened in order
|
UI: Expose an "is first search" boolean to search button callbacks
Currently when you open an RNA collection search button, like a
vertex group selector, the search filter isn't applied until you
start typing, in order to display every option at the start.
Otherwise they wouldn't be visible, since the search filter would
run for the current text.
Currently this check happens in one place, but it relies on the
`changed` value of `uiBut`. This is fine in the interface directory,
but anywhere else it would require exposing `uiBut.changed`, which
is probably too low-level to expose.
The solution is adding an `is_first` argument to the search callbacks,
which is nice for a few reasons:
- They work at a higher level of abstraction, meaning they don't
have to worry about how exactly to tell if this is the first
search.
- It makes it easier to do special behavior when the search menu
is first opened.
- Then, obviously, it makes that state accessible without including
`interface_intern.h`.
Needed for attribute search: T85658
Differential Revision: https://developer.blender.org/D10528
2021-03-02 11:42:05 -06:00
|
|
|
* to display the full list of options. The value will be false after the button's text is edited
|
2021-12-09 00:55:11 +11:00
|
|
|
* (for every call except the first).
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiButSearchUpdateFn =
|
|
|
|
|
void (*)(const bContext *C, void *arg, const char *str, uiSearchItems *items, bool is_first);
|
|
|
|
|
using uiButSearchContextMenuFn = bool (*)(bContext *C,
|
|
|
|
|
void *arg,
|
|
|
|
|
void *active,
|
|
|
|
|
const wmEvent *event);
|
|
|
|
|
using uiButSearchTooltipFn =
|
|
|
|
|
ARegion *(*)(bContext *C, ARegion *region, const rcti *item_rect, void *arg, void *active);
|
|
|
|
|
using uiButSearchListenFn = void (*)(const wmRegionListenerParams *params, void *arg);
|
2020-03-24 11:34:18 +11:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Must return an allocated string. */
|
2024-01-26 14:39:05 -05:00
|
|
|
using uiButToolTipFunc = std::string (*)(bContext *C, void *argN, const char *tip);
|
2015-02-11 00:06:03 +01:00
|
|
|
|
2024-07-26 12:24:33 +02:00
|
|
|
using uiButToolTipCustomFunc = void (*)(bContext &C, uiTooltipData &data, void *argN);
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiBlockHandleFunc = void (*)(bContext *C, void *arg, int event);
|
2011-11-24 13:51:31 +00:00
|
|
|
|
2021-07-08 16:23:41 +10:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Custom Interaction
|
|
|
|
|
*
|
|
|
|
|
* Sometimes it's useful to create data that remains available
|
|
|
|
|
* while the user interacts with a button.
|
|
|
|
|
*
|
|
|
|
|
* A common case is dragging a number button or slider
|
|
|
|
|
* however this could be used in other cases too.
|
|
|
|
|
* \{ */
|
|
|
|
|
|
|
|
|
|
struct uiBlockInteraction_Params {
|
|
|
|
|
/**
|
|
|
|
|
* When true, this interaction is not modal
|
|
|
|
|
* (user clicking on a number button arrows or pasting a value for example).
|
|
|
|
|
*/
|
|
|
|
|
bool is_click;
|
|
|
|
|
/**
|
|
|
|
|
* Array of unique event ID's (values from #uiBut.retval).
|
|
|
|
|
* There may be more than one for multi-button editing (see #UI_BUT_DRAG_MULTI).
|
|
|
|
|
*/
|
|
|
|
|
int *unique_retval_ids;
|
|
|
|
|
uint unique_retval_ids_len;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/** Returns 'user_data', freed by #uiBlockInteractionEndFn. */
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiBlockInteractionBeginFn = void *(*)(bContext *C,
|
|
|
|
|
const uiBlockInteraction_Params *params,
|
|
|
|
|
void *arg1);
|
|
|
|
|
using uiBlockInteractionEndFn = void (*)(bContext *C,
|
|
|
|
|
const uiBlockInteraction_Params *params,
|
|
|
|
|
void *arg1,
|
|
|
|
|
void *user_data);
|
|
|
|
|
using uiBlockInteractionUpdateFn = void (*)(bContext *C,
|
|
|
|
|
const uiBlockInteraction_Params *params,
|
|
|
|
|
void *arg1,
|
|
|
|
|
void *user_data);
|
|
|
|
|
|
|
|
|
|
struct uiBlockInteraction_CallbackData {
|
2021-07-08 16:23:41 +10:00
|
|
|
uiBlockInteractionBeginFn begin_fn;
|
|
|
|
|
uiBlockInteractionEndFn end_fn;
|
|
|
|
|
uiBlockInteractionUpdateFn update_fn;
|
|
|
|
|
void *arg1;
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2021-07-08 16:23:41 +10:00
|
|
|
|
|
|
|
|
void UI_block_interaction_set(uiBlock *block, uiBlockInteraction_CallbackData *callbacks);
|
|
|
|
|
|
|
|
|
|
/** \} */
|
|
|
|
|
|
2009-04-22 18:39:44 +00:00
|
|
|
/* Menu Callbacks */
|
2009-01-25 20:22:05 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiMenuCreateFunc = void (*)(bContext *C, uiLayout *layout, void *arg1);
|
|
|
|
|
using uiMenuHandleFunc = void (*)(bContext *C, void *arg, int event);
|
2015-11-16 06:26:25 +11:00
|
|
|
/**
|
|
|
|
|
* Used for cycling menu values without opening the menu (Ctrl-Wheel).
|
|
|
|
|
* \param direction: forward or backwards [1 / -1].
|
|
|
|
|
* \param arg1: uiBut.poin (as with #uiMenuCreateFunc).
|
|
|
|
|
* \return true when the button was changed.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiMenuStepFunc = bool (*)(bContext *C, int direction, void *arg1);
|
2009-01-25 20:22:05 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiCopyArgFunc = void *(*)(const void *arg);
|
|
|
|
|
using uiFreeArgFunc = void (*)(void *arg);
|
2021-06-30 17:27:54 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_query.cc` */
|
2022-04-04 13:17:03 +10:00
|
|
|
|
2018-09-05 13:52:19 +10:00
|
|
|
bool UI_but_has_tooltip_label(const uiBut *but);
|
2018-06-30 10:58:56 +02:00
|
|
|
bool UI_but_is_tool(const uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/* file selectors are exempt from utf-8 checks */
|
2019-09-04 16:19:48 +02:00
|
|
|
bool UI_but_is_utf8(const uiBut *but);
|
2020-08-07 14:34:11 +02:00
|
|
|
#define UI_but_is_decorator(but) ((but)->type == UI_BTYPE_DECORATOR)
|
2018-06-30 10:58:56 +02:00
|
|
|
|
2022-01-07 11:38:08 +11:00
|
|
|
bool UI_block_is_empty_ex(const uiBlock *block, bool skip_title);
|
2018-06-30 10:36:40 +02:00
|
|
|
bool UI_block_is_empty(const uiBlock *block);
|
2019-04-25 14:40:53 +02:00
|
|
|
bool UI_block_can_add_separator(const uiBlock *block);
|
2024-07-06 14:49:39 +10:00
|
|
|
/**
|
|
|
|
|
* Return true when the block has a default button.
|
|
|
|
|
* Use this for popups to detect when pressing "Return" will run an action.
|
|
|
|
|
*/
|
|
|
|
|
bool UI_block_has_active_default_button(const uiBlock *block);
|
2018-06-30 10:36:40 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiList *UI_list_find_mouse_over(const ARegion *region, const wmEvent *event);
|
2021-07-09 21:46:55 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_menu_popup.cc` */
|
2022-04-04 13:17:03 +10:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/**
|
|
|
|
|
* Popup Menus
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
*
|
|
|
|
|
* Functions used to create popup menus. For more extended menus the
|
2014-11-09 21:20:40 +01:00
|
|
|
* UI_popup_menu_begin/End functions can be used to define own items with
|
2011-01-02 11:06:50 +00:00
|
|
|
* the uiItem functions in between. If it is a simple confirmation menu
|
2019-01-14 15:58:40 +11:00
|
|
|
* or similar, popups can be created with a single function call.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiPopupMenu;
|
2009-04-22 18:39:44 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiPopupMenu *UI_popup_menu_begin(bContext *C, const char *title, int icon) ATTR_NONNULL();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2023-03-29 14:16:31 +11:00
|
|
|
* Directly create a popup menu that is not refreshed on redraw.
|
|
|
|
|
*
|
2021-12-09 00:55:11 +11:00
|
|
|
* Only return handler, and set optional title.
|
|
|
|
|
* \param block_name: Assigned to uiBlock.name (useful info for debugging).
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
uiPopupMenu *UI_popup_menu_begin_ex(bContext *C,
|
2016-07-26 19:30:18 +02:00
|
|
|
const char *title,
|
|
|
|
|
const char *block_name,
|
|
|
|
|
int icon) ATTR_NONNULL();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Set the whole structure to work.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_menu_end(bContext *C, uiPopupMenu *pup);
|
|
|
|
|
bool UI_popup_menu_end_or_cancel(bContext *C, uiPopupMenu *pup);
|
|
|
|
|
uiLayout *UI_popup_menu_layout(uiPopupMenu *pup);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_menu_reports(bContext *C, ReportList *reports) ATTR_NONNULL();
|
|
|
|
|
int UI_popup_menu_invoke(bContext *C, const char *idname, ReportList *reports) ATTR_NONNULL(1, 2);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2024-05-16 00:11:47 +02:00
|
|
|
/**
|
|
|
|
|
* If \a block is displayed in a popup menu, tag it for closing.
|
|
|
|
|
* \param is_cancel: If set to true, the popup will be closed as being cancelled (e.g. when
|
|
|
|
|
* pressing escape) as opposed to being handled successfully.
|
|
|
|
|
*/
|
|
|
|
|
void UI_popup_menu_close(const uiBlock *block, bool is_cancel = false);
|
|
|
|
|
/**
|
|
|
|
|
* Version of #UI_popup_menu_close() that can be called on a button contained in a popup menu
|
|
|
|
|
* block. Convenience since the block may not be available.
|
|
|
|
|
*/
|
|
|
|
|
void UI_popup_menu_close_from_but(const uiBut *but, bool is_cancel = false);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Allow setting menu return value from externals.
|
|
|
|
|
* E.g. WM might need to do this for exiting files correctly.
|
|
|
|
|
*/
|
2022-01-07 11:38:08 +11:00
|
|
|
void UI_popup_menu_retval_set(const uiBlock *block, int retval, bool enable);
|
2024-03-21 10:31:05 +01:00
|
|
|
/**
|
|
|
|
|
* Set a dummy panel in the popup `block` to support using layout panels, the panel is linked
|
|
|
|
|
* to the popup `region` so layout panels state can be persistent until the popup is closed.
|
|
|
|
|
*/
|
|
|
|
|
void UI_popup_dummy_panel_set(ARegion *region, uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Setting the button makes the popup open from the button instead of the cursor.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_menu_but_set(uiPopupMenu *pup, ARegion *butregion, uiBut *but);
|
2016-09-01 16:25:42 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_popover.cc` */
|
2018-04-22 17:16:39 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiPopover;
|
2018-04-22 17:16:39 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_popover_panel_invoke(bContext *C, const char *idname, bool keep_open, ReportList *reports);
|
2018-05-23 19:46:40 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Only return handler, and set optional title.
|
|
|
|
|
*
|
|
|
|
|
* \param from_active_button: Use the active button for positioning,
|
|
|
|
|
* use when the popover is activated from an operator instead of directly from the button.
|
|
|
|
|
*/
|
2024-07-27 13:20:43 +10:00
|
|
|
uiPopover *UI_popover_begin(bContext *C, int ui_menu_width, bool from_active_button)
|
|
|
|
|
ATTR_NONNULL(1);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Set the whole structure to work.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popover_end(bContext *C, uiPopover *pup, wmKeyMap *keymap);
|
|
|
|
|
uiLayout *UI_popover_layout(uiPopover *pup);
|
2018-05-19 19:16:47 +02:00
|
|
|
void UI_popover_once_clear(uiPopover *pup);
|
2018-04-22 17:16:39 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_menu_pie.cc` */
|
2022-04-04 13:17:03 +10:00
|
|
|
|
Pie Menus C code backend.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
2014-08-11 10:39:59 +02:00
|
|
|
/* Pie menus */
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiPieMenu;
|
Pie Menus C code backend.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
2014-08-11 10:39:59 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_pie_menu_invoke(bContext *C, const char *idname, const wmEvent *event);
|
|
|
|
|
int UI_pie_menu_invoke_from_operator_enum(bContext *C,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull title,
|
|
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
const wmEvent *event);
|
|
|
|
|
int UI_pie_menu_invoke_from_rna_enum(bContext *C,
|
2014-11-09 21:20:40 +01:00
|
|
|
const char *title,
|
|
|
|
|
const char *path,
|
2023-08-04 22:15:25 -04:00
|
|
|
const wmEvent *event);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiPieMenu *UI_pie_menu_begin(bContext *C, const char *title, int icon, const wmEvent *event)
|
|
|
|
|
ATTR_NONNULL();
|
|
|
|
|
void UI_pie_menu_end(bContext *C, uiPieMenu *pie);
|
|
|
|
|
uiLayout *UI_pie_menu_layout(uiPieMenu *pie);
|
2017-11-03 20:26:35 +11:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_menu_popup.cc` */
|
2017-11-03 20:26:35 +11:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Popup Blocks
|
|
|
|
|
*
|
|
|
|
|
* Functions used to create popup blocks. These are like popup menus
|
2024-03-07 16:20:36 -05:00
|
|
|
* but allow using all button types and creating their own layout. */
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiBlockCreateFunc = uiBlock *(*)(bContext *C, ARegion *region, void *arg1);
|
|
|
|
|
using uiBlockCancelFunc = void (*)(bContext *C, void *arg1);
|
2009-02-04 11:52:16 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_block_invoke(bContext *C, uiBlockCreateFunc func, void *arg, uiFreeArgFunc arg_free);
|
2024-05-14 14:08:28 +10:00
|
|
|
/**
|
|
|
|
|
* \param can_refresh: When true, the popup may be refreshed (updated after creation).
|
|
|
|
|
* \note It can be useful to disable refresh (even though it will work)
|
|
|
|
|
* as this exits text fields which can be disruptive if refresh isn't needed.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_block_invoke_ex(
|
|
|
|
|
bContext *C, uiBlockCreateFunc func, void *arg, uiFreeArgFunc arg_free, bool can_refresh);
|
|
|
|
|
void UI_popup_block_ex(bContext *C,
|
2017-03-30 16:48:18 +03:00
|
|
|
uiBlockCreateFunc func,
|
|
|
|
|
uiBlockHandleFunc popup_func,
|
|
|
|
|
uiBlockCancelFunc cancel_func,
|
|
|
|
|
void *arg,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperator *op);
|
2024-07-06 14:49:39 +10:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Return true when #UI_popup_block_template_confirm and related functions are supported.
|
|
|
|
|
*/
|
|
|
|
|
bool UI_popup_block_template_confirm_is_supported(const uiBlock *block);
|
|
|
|
|
/**
|
|
|
|
|
* Create confirm & cancel buttons in a popup using callback functions.
|
|
|
|
|
*/
|
|
|
|
|
void UI_popup_block_template_confirm(uiBlock *block,
|
|
|
|
|
bool cancel_default,
|
|
|
|
|
blender::FunctionRef<uiBut *()> confirm_fn,
|
|
|
|
|
blender::FunctionRef<uiBut *()> cancel_fn);
|
|
|
|
|
/**
|
|
|
|
|
* Create confirm & cancel buttons in a popup using an operator.
|
|
|
|
|
*
|
|
|
|
|
* \param confirm_text: The text to confirm, null for default text or an empty string to hide.
|
|
|
|
|
* \param cancel_text: The text to cancel, null for default text or an empty string to hide.
|
|
|
|
|
* \param r_ptr: The pointer for operator properties, set a "confirm" button has been created.
|
|
|
|
|
*/
|
|
|
|
|
void UI_popup_block_template_confirm_op(uiLayout *layout,
|
|
|
|
|
wmOperatorType *ot,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> confirm_text,
|
|
|
|
|
std::optional<blender::StringRef> cancel_text,
|
2024-07-06 14:49:39 +10:00
|
|
|
const int icon,
|
|
|
|
|
bool cancel_default,
|
|
|
|
|
PointerRNA *r_ptr);
|
|
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
#if 0 /* UNUSED */
|
2023-08-09 10:47:43 +10:00
|
|
|
void uiPupBlockOperator(bContext *C,
|
2019-04-17 08:24:14 +02:00
|
|
|
uiBlockCreateFunc func,
|
2023-08-09 10:47:43 +10:00
|
|
|
wmOperator *op,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext);
|
2019-01-15 23:24:20 +11:00
|
|
|
#endif
|
2009-01-25 20:22:05 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_popup_block_close(bContext *C, wmWindow *win, uiBlock *block);
|
2009-11-23 13:58:55 +00:00
|
|
|
|
2024-01-18 15:59:20 -05:00
|
|
|
bool UI_popup_block_name_exists(const bScreen *screen, blender::StringRef name);
|
2019-01-04 14:23:49 +01:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Blocks
|
|
|
|
|
*
|
|
|
|
|
* Functions for creating, drawing and freeing blocks. A Block is a
|
|
|
|
|
* container of buttons and used for various purposes.
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
* Begin/Define Buttons/End/Draw is the typical order in which these
|
|
|
|
|
* function should be called, though for popup blocks Draw is left out.
|
|
|
|
|
* Freeing blocks is done by the screen/ module automatically.
|
2021-01-20 15:15:38 +11:00
|
|
|
*/
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBlock *UI_block_begin(const bContext *C,
|
|
|
|
|
ARegion *region,
|
2024-01-18 15:59:20 -05:00
|
|
|
std::string name,
|
2020-12-19 10:07:13 -06:00
|
|
|
eUIEmbossType emboss);
|
2024-11-14 16:04:33 +01:00
|
|
|
uiBlock *UI_block_begin(const bContext *C,
|
|
|
|
|
Scene *scene,
|
|
|
|
|
wmWindow *window,
|
|
|
|
|
ARegion *region,
|
|
|
|
|
std::string name,
|
|
|
|
|
eUIEmbossType emboss);
|
|
|
|
|
void UI_block_end_ex(const bContext *C,
|
|
|
|
|
Main *bmain,
|
|
|
|
|
wmWindow *window,
|
|
|
|
|
Scene *scene,
|
|
|
|
|
ARegion *region,
|
|
|
|
|
Depsgraph *depsgraph,
|
|
|
|
|
uiBlock *block,
|
|
|
|
|
const int xy[2] = nullptr,
|
|
|
|
|
int r_xy[2] = nullptr);
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_end(const bContext *C, uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Uses local copy of style, to scale things down, and allow widgets to change stuff.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_draw(const bContext *C, uiBlock *block);
|
|
|
|
|
void UI_blocklist_update_window_matrix(const bContext *C, const ListBase *lb);
|
|
|
|
|
void UI_blocklist_update_view_for_buttons(const bContext *C, const ListBase *lb);
|
|
|
|
|
void UI_blocklist_draw(const bContext *C, const ListBase *lb);
|
|
|
|
|
void UI_block_update_from_old(const bContext *C, uiBlock *block);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2018-09-11 10:56:08 +10:00
|
|
|
enum {
|
|
|
|
|
UI_BLOCK_THEME_STYLE_REGULAR = 0,
|
|
|
|
|
UI_BLOCK_THEME_STYLE_POPUP = 1,
|
|
|
|
|
};
|
|
|
|
|
void UI_block_theme_style_set(uiBlock *block, char theme_style);
|
2021-07-05 14:52:21 -05:00
|
|
|
eUIEmbossType UI_block_emboss_get(uiBlock *block);
|
2020-12-19 10:07:13 -06:00
|
|
|
void UI_block_emboss_set(uiBlock *block, eUIEmbossType emboss);
|
2020-09-15 11:25:49 -05:00
|
|
|
bool UI_block_is_search_only(const uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Use when a block must be searched to give accurate results
|
|
|
|
|
* for the whole region but shouldn't be displayed.
|
|
|
|
|
*/
|
2020-09-15 11:25:49 -05:00
|
|
|
void UI_block_set_search_only(uiBlock *block, bool search_only);
|
2.5
More cleanup!
- removed old UI font completely, including from uiBeginBlock
- emboss hints for uiBlock only have three types now;
Regular, Pulldown, or "Nothing" (only icon/text)
- removed old font path from Userdef
- removed all old button theme hinting
- removed old "auto block" to merge buttons in groups
(was only in use for radiosity buttons)
And went over all warnings. One hooray for make giving clean output :)
Well, we need uniform definitions for warnings, so people at least fix
them... here's the real bad bugs I found:
- in mesh code, a call to editmesh mixed *em and *me
- in armature, ED_util.h was not included, so no warnings for wrong call
to ED_undo_push()
- The extern Py api .h was not included in the bpy_interface.c, showing
a several calls using different args.
Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
|
|
|
|
2024-03-28 20:40:59 +01:00
|
|
|
/**
|
|
|
|
|
* Used for operator presets.
|
|
|
|
|
*/
|
|
|
|
|
void UI_block_set_active_operator(uiBlock *block, wmOperator *op, const bool free);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Can be called with C==NULL.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_free(const bContext *C, uiBlock *block);
|
2022-11-01 17:36:36 +01:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_listen(const uiBlock *block, const wmRegionListenerParams *listener_params);
|
2022-11-01 17:36:36 +01:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Can be called with C==NULL.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_blocklist_free(const bContext *C, ARegion *region);
|
|
|
|
|
void UI_blocklist_free_inactive(const bContext *C, ARegion *region);
|
2021-12-02 15:46:14 +11:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Is called by notifier.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_screen_free_active_but_highlight(const bContext *C, bScreen *screen);
|
2024-07-27 13:20:43 +10:00
|
|
|
void UI_region_free_active_but_all(bContext *C, ARegion *region);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_region_set(uiBlock *block, ARegion *region);
|
UI: Layout Engine
* Buttons are now created first, and after that the layout is computed.
This means the layout engine now works at button level, and makes it
easier to write templates. Otherwise you had to store all info and
create the buttons later.
* Added interface_templates.c as a separate file to put templates in.
These can contain regular buttons, and can be put in a Free layout,
which means you can specify manual coordinates, but still get nested
correct inside other layouts.
* API was changed to allow better nesting. Previously items were added
in the last added layout specifier, i.e. one level up in the layout
hierarchy. This doesn't work well in always, so now when creating things
like rows or columns it always returns a layout which you have to add
the items in. All py scripts were updated to follow this.
* Computing the layout now goes in two passes, first estimating the
required width/height of all nested layouts, and then in the second
pass using the results of that to decide on the actual locations.
* Enum and array buttons now follow the direction of the layout, i.e.
they are vertical or horizontal depending if they are in a column or row.
* Color properties now get a color picker, and only get the additional
RGB sliders with Expand=True.
* File/directory string properties now get a button next to them for
opening the file browse, though this is not implemented yet.
* Layout items can now be aligned, set align=True when creating a column,
row, etc.
* Buttons now get a minimum width of one icon (avoids squashing icon
buttons).
* Moved some more space variables into Style.
2009-05-15 11:19:59 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_lock_set(uiBlock *block, bool val, const char *lockstr);
|
|
|
|
|
void UI_block_lock_clear(uiBlock *block);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-09-26 17:12:37 +02:00
|
|
|
#define UI_BUTTON_SECTION_MERGE_DISTANCE (UI_UNIT_X * 3)
|
|
|
|
|
/* Separator line between regions if the #uiButtonSectionsAlign is not #None. */
|
|
|
|
|
#define UI_BUTTON_SECTION_SEPERATOR_LINE_WITH (U.pixelsize * 2)
|
|
|
|
|
|
|
|
|
|
enum class uiButtonSectionsAlign : int8_t { None = 1, Top, Bottom };
|
|
|
|
|
/**
|
|
|
|
|
* Draw a background with rounded corners behind each visual group of buttons. The visual groups
|
|
|
|
|
* are separated by spacer buttons (#uiItemSpacer()). Button groups that are closer than
|
|
|
|
|
* #UI_BUTTON_SECTION_MERGE_DISTANCE will be merged into one visual section. If the group is closer
|
|
|
|
|
* than that to a region edge, it will also be extended to that, and the rounded corners will be
|
|
|
|
|
* removed on that edge.
|
|
|
|
|
*
|
|
|
|
|
* \note This currently only works well for horizontal, header like regions.
|
|
|
|
|
*/
|
|
|
|
|
void UI_region_button_sections_draw(const ARegion *region,
|
|
|
|
|
int /*THemeColorID*/ colorid,
|
|
|
|
|
uiButtonSectionsAlign align);
|
|
|
|
|
bool UI_region_button_sections_is_inside_x(const ARegion *region, const int mval_x);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Automatic aligning, horizontal or vertical.
|
|
|
|
|
*/
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_align_begin(uiBlock *block);
|
|
|
|
|
void UI_block_align_end(uiBlock *block);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Block bounds/position calculation. */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eBlockBoundsCalc {
|
2012-09-10 07:03:30 +00:00
|
|
|
UI_BLOCK_BOUNDS_NONE = 0,
|
2012-05-12 20:39:39 +00:00
|
|
|
UI_BLOCK_BOUNDS = 1,
|
2009-11-23 13:58:55 +00:00
|
|
|
UI_BLOCK_BOUNDS_TEXT,
|
|
|
|
|
UI_BLOCK_BOUNDS_POPUP_MOUSE,
|
|
|
|
|
UI_BLOCK_BOUNDS_POPUP_MENU,
|
Pie Menus C code backend.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
2014-08-11 10:39:59 +02:00
|
|
|
UI_BLOCK_BOUNDS_POPUP_CENTER,
|
|
|
|
|
UI_BLOCK_BOUNDS_PIE_CENTER,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2009-11-23 13:58:55 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for various cases.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_block_bounds_set_normal(uiBlock *block, int addval);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for pull-downs.
|
|
|
|
|
*/
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_bounds_set_text(uiBlock *block, int addval);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for block popups.
|
|
|
|
|
*/
|
2019-03-13 16:35:24 +11:00
|
|
|
void UI_block_bounds_set_popup(uiBlock *block, int addval, const int bounds_offset[2]);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for menu popups.
|
|
|
|
|
*/
|
2019-03-13 16:35:24 +11:00
|
|
|
void UI_block_bounds_set_menu(uiBlock *block, int addval, const int bounds_offset[2]);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for centered popups, i.e. splash.
|
|
|
|
|
*/
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_bounds_set_centered(uiBlock *block, int addval);
|
|
|
|
|
void UI_block_bounds_set_explicit(uiBlock *block, int minx, int miny, int maxx, int maxy);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_blocklist_min_y_get(ListBase *lb);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_direction_set(uiBlock *block, char direction);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This call escapes if there's alignment flags.
|
|
|
|
|
*/
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_flag_enable(uiBlock *block, int flag);
|
|
|
|
|
void UI_block_flag_disable(uiBlock *block, int flag);
|
2024-09-13 20:04:15 +02:00
|
|
|
void UI_block_translate(uiBlock *block, float x, float y);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
int UI_but_return_value_get(uiBut *but);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBut *UI_but_active_drop_name_button(const bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Returns true if highlighted button allows drop of names.
|
|
|
|
|
* called in region context.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_but_active_drop_name(const bContext *C);
|
|
|
|
|
bool UI_but_active_drop_color(bContext *C);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2022-05-12 15:53:12 +02:00
|
|
|
void UI_but_flag_enable(uiBut *but, int flag);
|
|
|
|
|
void UI_but_flag_disable(uiBut *but, int flag);
|
|
|
|
|
bool UI_but_flag_is_set(uiBut *but, int flag);
|
2023-09-06 18:16:45 +02:00
|
|
|
void UI_but_flag2_enable(uiBut *but, int flag);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_drawflag_enable(uiBut *but, int flag);
|
|
|
|
|
void UI_but_drawflag_disable(uiBut *but, int flag);
|
2012-05-23 14:24:40 +00:00
|
|
|
|
2023-02-20 11:51:16 +01:00
|
|
|
void UI_but_dragflag_enable(uiBut *but, int flag);
|
|
|
|
|
void UI_but_dragflag_disable(uiBut *but, int flag);
|
|
|
|
|
|
2020-09-03 17:39:57 +02:00
|
|
|
void UI_but_disable(uiBut *but, const char *disabled_hint);
|
|
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_type_set_menu_from_pulldown(uiBut *but);
|
2024-08-30 20:52:17 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Sets the button's color, normally only used to recolor the icon. In the
|
|
|
|
|
* special case of UI_BTYPE_LABEL without icon this is used as text color.
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_color_set(uiBut *but, const uchar color[4]);
|
2014-02-12 00:08:54 +11:00
|
|
|
|
2023-10-12 11:44:08 -07:00
|
|
|
/**
|
|
|
|
|
* Set at hint that describes the expected value when empty.
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_placeholder_set(uiBut *but, const char *placeholder_text) ATTR_NONNULL(1);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Special button case, only draw it when used actively, for outliner etc.
|
|
|
|
|
*
|
|
|
|
|
* Needed for temporarily rename buttons, such as in outliner or file-select,
|
|
|
|
|
* they should keep calling #uiDefBut to keep them alive.
|
|
|
|
|
* \return false when button removed.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_but_active_only_ex(
|
|
|
|
|
const bContext *C, ARegion *region, uiBlock *block, uiBut *but, bool remove_on_failure);
|
|
|
|
|
bool UI_but_active_only(const bContext *C, ARegion *region, uiBlock *block, uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \warning This must run after other handlers have been added,
|
2023-02-12 14:37:16 +11:00
|
|
|
* otherwise the handler won't be removed, see: #71112.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_block_active_only_flagged_buttons(const bContext *C, ARegion *region, uiBlock *block);
|
2009-07-25 13:40:59 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Simulate button click.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_execute(const bContext *C, ARegion *region, uiBut *but);
|
2013-02-22 05:56:20 +00:00
|
|
|
|
2024-02-19 12:17:52 +11:00
|
|
|
std::optional<std::string> UI_but_online_manual_id(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
std::optional<std::string> UI_but_online_manual_id_from_active(const bContext *C)
|
|
|
|
|
ATTR_WARN_UNUSED_RESULT;
|
2020-06-11 17:24:00 +10:00
|
|
|
bool UI_but_is_userdef(const uiBut *but);
|
2009-07-25 13:40:59 +00:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Buttons
|
|
|
|
|
*
|
|
|
|
|
* Functions to define various types of buttons in a block. Postfixes:
|
|
|
|
|
* - F: float
|
|
|
|
|
* - I: int
|
|
|
|
|
* - S: short
|
|
|
|
|
* - C: char
|
|
|
|
|
* - R: RNA
|
|
|
|
|
* - O: operator */
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2018-07-09 06:38:07 +02:00
|
|
|
uiBut *uiDefBut(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2020-09-04 20:59:13 +02:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2018-07-09 06:38:07 +02:00
|
|
|
void *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefButF(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
float *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButI(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
int *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButBitI(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
int *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButS(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
short *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButBitS(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
short *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButC(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
char *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButBitC(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
char *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButR(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
const blender::StringRefNull propname,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButR_prop(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButO(uiBlock *block,
|
|
|
|
|
int type,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2024-12-06 14:08:10 +01:00
|
|
|
const std::optional<blender::StringRef> str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefButO_ptr(uiBlock *block,
|
|
|
|
|
int type,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2024-02-01 14:40:33 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-07-09 06:38:07 +02:00
|
|
|
uiBut *uiDefIconBut(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2020-09-04 20:59:13 +02:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2018-07-09 06:38:07 +02:00
|
|
|
void *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefIconButI(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
int *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButBitI(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
int *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButS(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
short *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButBitS(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
short *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButBitC(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int bit,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
char *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButR(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButR_prop(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButO(uiBlock *block,
|
|
|
|
|
int type,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2012-08-18 18:11:51 +00:00
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconButO_ptr(uiBlock *block,
|
|
|
|
|
int type,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2012-08-18 18:11:51 +00:00
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
2020-03-14 11:05:09 -07:00
|
|
|
uiBut *uiDefButImage(
|
|
|
|
|
uiBlock *block, void *imbuf, int x, int y, short width, short height, const uchar color[4]);
|
2020-03-15 17:32:06 +11:00
|
|
|
uiBut *uiDefButAlert(uiBlock *block, int icon, int x, int y, short width, short height);
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Button containing both string label and icon. */
|
2018-07-09 06:38:07 +02:00
|
|
|
uiBut *uiDefIconTextBut(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2020-09-04 20:59:13 +02:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2018-07-09 06:38:07 +02:00
|
|
|
void *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefIconTextButI(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
int *poin,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconTextButR(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconTextButR_prop(uiBlock *block,
|
|
|
|
|
int type,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2012-08-18 18:11:51 +00:00
|
|
|
int index,
|
|
|
|
|
float min,
|
|
|
|
|
float max,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconTextButO(uiBlock *block,
|
|
|
|
|
int type,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2012-08-18 18:11:51 +00:00
|
|
|
int icon,
|
2024-02-01 14:40:33 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconTextButO_ptr(uiBlock *block,
|
|
|
|
|
int type,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext opcontext,
|
2012-08-18 18:11:51 +00:00
|
|
|
int icon,
|
2024-02-01 14:40:33 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2024-07-01 20:21:25 +02:00
|
|
|
void UI_but_operator_set(uiBut *but,
|
|
|
|
|
wmOperatorType *optype,
|
|
|
|
|
wmOperatorCallContext opcontext,
|
|
|
|
|
const PointerRNA *opptr = nullptr);
|
2024-07-12 10:02:10 +02:00
|
|
|
/**
|
|
|
|
|
* Disable calling operators from \a but in button handling. Useful to attach an operator to a
|
|
|
|
|
* button for tooltips, "Assign Shortcut", etc. without actually making the button execute the
|
|
|
|
|
* operator.
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_operator_set_never_call(uiBut *but);
|
2024-07-01 20:21:25 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** For passing inputs to ButO buttons. */
|
2024-01-29 10:19:05 -05:00
|
|
|
PointerRNA *UI_but_operator_ptr_ensure(uiBut *but);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2024-12-06 14:08:10 +01:00
|
|
|
void UI_but_context_ptr_set(uiBlock *block,
|
|
|
|
|
uiBut *but,
|
|
|
|
|
blender::StringRef name,
|
|
|
|
|
const PointerRNA *ptr);
|
2024-12-10 14:49:11 +01:00
|
|
|
void UI_but_context_int_set(uiBlock *block, uiBut *but, blender::StringRef name, int64_t value);
|
2023-08-04 22:15:25 -04:00
|
|
|
const PointerRNA *UI_but_context_ptr_get(const uiBut *but,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRef name,
|
2023-12-30 23:12:42 -05:00
|
|
|
const StructRNA *type = nullptr);
|
2024-05-27 18:46:19 +02:00
|
|
|
std::optional<blender::StringRefNull> UI_but_context_string_get(const uiBut *but,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRef name);
|
2024-12-10 14:49:11 +01:00
|
|
|
std::optional<int64_t> UI_but_context_int_get(const uiBut *but, blender::StringRef name);
|
2023-08-31 11:59:58 -04:00
|
|
|
const bContextStore *UI_but_context_get(const uiBut *but);
|
2022-01-28 16:42:23 +01:00
|
|
|
|
2022-01-07 11:38:08 +11:00
|
|
|
void UI_but_unit_type_set(uiBut *but, int unit_type);
|
2014-11-09 21:20:40 +01:00
|
|
|
int UI_but_unit_type_get(const uiBut *but);
|
2010-12-10 04:10:21 +00:00
|
|
|
|
2024-01-18 23:12:09 -05:00
|
|
|
std::optional<EnumPropertyItem> UI_but_rna_enum_item_get(bContext &C, uiBut &but);
|
|
|
|
|
|
|
|
|
|
std::string UI_but_string_get_rna_property_identifier(const uiBut &but);
|
|
|
|
|
std::string UI_but_string_get_rna_struct_identifier(const uiBut &but);
|
|
|
|
|
std::string UI_but_string_get_label(uiBut &but);
|
2024-06-05 11:28:44 +02:00
|
|
|
std::string UI_but_context_menu_title_from_button(uiBut &but);
|
2024-01-18 23:12:09 -05:00
|
|
|
/**
|
|
|
|
|
* Query the result of #uiBut::tip_label_func().
|
|
|
|
|
* Meant to allow overriding the label to be displayed in the tool-tip.
|
|
|
|
|
*/
|
|
|
|
|
std::string UI_but_string_get_tooltip_label(const uiBut &but);
|
|
|
|
|
std::string UI_but_string_get_rna_label(uiBut &but);
|
|
|
|
|
/** Context specified in `CTX_*_` macros are just unreachable! */
|
|
|
|
|
std::string UI_but_string_get_rna_label_context(const uiBut &but);
|
|
|
|
|
std::string UI_but_string_get_tooltip(bContext &C, uiBut &but);
|
|
|
|
|
std::string UI_but_string_get_rna_tooltip(bContext &C, uiBut &but);
|
|
|
|
|
/** Buttons assigned to an operator (common case). */
|
|
|
|
|
std::string UI_but_string_get_operator_keymap(bContext &C, uiBut &but);
|
|
|
|
|
/** Use for properties that are bound to one of the context cycle, etc. keys. */
|
|
|
|
|
std::string UI_but_string_get_property_keymap(bContext &C, uiBut &but);
|
|
|
|
|
|
|
|
|
|
std::string UI_but_extra_icon_string_get_label(const uiButExtraOpIcon &extra_icon);
|
|
|
|
|
std::string UI_but_extra_icon_string_get_tooltip(bContext &C, const uiButExtraOpIcon &extra_icon);
|
|
|
|
|
std::string UI_but_extra_icon_string_get_operator_keymap(const bContext &C,
|
|
|
|
|
const uiButExtraOpIcon &extra_icon);
|
UI translation from inside Blender UI: first part.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
/**
|
|
|
|
|
* Special Buttons
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
*
|
2012-03-01 12:20:18 +00:00
|
|
|
* Buttons with a more specific purpose:
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
* - MenuBut: buttons that popup a menu (in headers usually).
|
|
|
|
|
* - PulldownBut: like MenuBut, but creating a uiBlock (for compatibility).
|
|
|
|
|
* - BlockBut: buttons that popup a block with more buttons.
|
|
|
|
|
* - KeyevtBut: buttons that can be used to turn key events into values.
|
2009-02-04 11:52:16 +00:00
|
|
|
* - PickerButtons: buttons like the color picker (for code sharing).
|
2019-01-14 15:58:40 +11:00
|
|
|
* - AutoButR: RNA property button with type automatically defined.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
2022-10-03 18:13:57 +02:00
|
|
|
UI_ID_NOP = 0,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_ID_RENAME = 1 << 0,
|
|
|
|
|
UI_ID_BROWSE = 1 << 1,
|
|
|
|
|
UI_ID_ADD_NEW = 1 << 2,
|
|
|
|
|
UI_ID_ALONE = 1 << 4,
|
|
|
|
|
UI_ID_OPEN = 1 << 3,
|
|
|
|
|
UI_ID_DELETE = 1 << 5,
|
2021-01-13 15:08:09 +01:00
|
|
|
UI_ID_LOCAL = 1 << 6,
|
|
|
|
|
UI_ID_AUTO_NAME = 1 << 7,
|
|
|
|
|
UI_ID_FAKE_USER = 1 << 8,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_ID_PIN = 1 << 9,
|
|
|
|
|
UI_ID_PREVIEWS = 1 << 10,
|
2021-01-13 15:08:09 +01:00
|
|
|
UI_ID_OVERRIDE = 1 << 11,
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_ID_FULL = UI_ID_RENAME | UI_ID_BROWSE | UI_ID_ADD_NEW | UI_ID_OPEN | UI_ID_ALONE |
|
2021-01-13 15:08:09 +01:00
|
|
|
UI_ID_DELETE | UI_ID_LOCAL,
|
2019-01-14 15:58:40 +11:00
|
|
|
};
|
2.5: ID datablock button back, previously known as std_libbuttons. The
way this worked in 2.4x wasn't really clean, with events going all over
the place and using dubious variables such as G.but->lockpoin or
G.sima->menunr. It works as follows now, for example:
xco= uiDefIDPoinButs(block, CTX_data_main(C), NULL, (ID**)&sima->image, ID_IM, &sima->pin, xco, yco,
sima_idpoin_handle, UI_ID_BROWSE|UI_ID_RENAME|UI_ID_ADD_NEW|UI_ID_OPEN|UI_ID_DELETE|UI_ID_ALONE|UI_ID_PIN);
The last two parameters are a callback function, and a list of events
or functionalities that are supported. The callback function will then
get the ID pointer + event to handle.
2009-02-06 16:40:14 +00:00
|
|
|
|
2018-01-03 21:54:02 +11:00
|
|
|
/**
|
|
|
|
|
* Ways to limit what is displayed in ID-search popup.
|
|
|
|
|
* \note We may want to add LOCAL, LIBRARY ... as needed.
|
|
|
|
|
*/
|
|
|
|
|
enum {
|
|
|
|
|
UI_TEMPLATE_ID_FILTER_ALL = 0,
|
|
|
|
|
UI_TEMPLATE_ID_FILTER_AVAILABLE = 1,
|
|
|
|
|
};
|
|
|
|
|
|
2023-07-12 13:18:06 +10:00
|
|
|
enum eButProgressType {
|
|
|
|
|
UI_BUT_PROGRESS_TYPE_BAR = 0,
|
|
|
|
|
UI_BUT_PROGRESS_TYPE_RING = 1,
|
|
|
|
|
};
|
|
|
|
|
|
2024-02-09 17:38:36 +01:00
|
|
|
enum class LayoutSeparatorType : int8_t {
|
|
|
|
|
Auto,
|
|
|
|
|
Space,
|
|
|
|
|
Line,
|
|
|
|
|
};
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/***************************** ID Utilities *******************************/
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_icon_from_id(const ID *id);
|
2021-12-09 00:55:11 +11:00
|
|
|
/** See: #BKE_report_type_str */
|
2014-11-09 21:20:40 +01:00
|
|
|
int UI_icon_from_report_type(int type);
|
2021-02-08 08:19:23 -08:00
|
|
|
int UI_icon_colorid_from_report_type(int type);
|
|
|
|
|
int UI_text_colorid_from_report_type(int type);
|
2009-09-16 01:15:30 +00:00
|
|
|
|
2018-07-08 11:57:59 +02:00
|
|
|
int UI_icon_from_event_type(short event_type, short event_value);
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_icon_from_keymap_item(const wmKeyMapItem *kmi, int r_icon_mod[4]);
|
2018-07-08 11:57:59 +02:00
|
|
|
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefMenuBut(uiBlock *block,
|
|
|
|
|
uiMenuCreateFunc func,
|
|
|
|
|
void *arg,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconTextMenuBut(uiBlock *block,
|
|
|
|
|
uiMenuCreateFunc func,
|
|
|
|
|
void *arg,
|
|
|
|
|
int icon,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefIconMenuBut(uiBlock *block,
|
|
|
|
|
uiMenuCreateFunc func,
|
|
|
|
|
void *arg,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefBlockBut(uiBlock *block,
|
|
|
|
|
uiBlockCreateFunc func,
|
2020-09-04 20:59:13 +02:00
|
|
|
void *arg,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
|
|
|
|
uiBut *uiDefBlockButN(uiBlock *block,
|
|
|
|
|
uiBlockCreateFunc func,
|
|
|
|
|
void *argN,
|
2024-01-31 17:16:25 -05:00
|
|
|
blender::StringRef str,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2024-07-05 17:09:40 +02:00
|
|
|
const char *tip,
|
|
|
|
|
uiButArgNFree func_argN_free_fn = MEM_freeN,
|
|
|
|
|
uiButArgNCopy func_argN_copy_fn = MEM_dupallocN);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Block button containing icon.
|
|
|
|
|
*/
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefIconBlockBut(uiBlock *block,
|
|
|
|
|
uiBlockCreateFunc func,
|
|
|
|
|
void *arg,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2021-12-14 15:49:31 +11:00
|
|
|
* \param arg: A pointer to string/name, use #UI_but_func_search_set() below to make this work.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2012-08-18 18:11:51 +00:00
|
|
|
uiBut *uiDefSearchBut(uiBlock *block,
|
|
|
|
|
void *arg,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-07-27 13:20:43 +10:00
|
|
|
int maxncpy,
|
2012-08-18 18:11:51 +00:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
2018-08-07 10:38:20 +02:00
|
|
|
const char *tip);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Same parameters as for #uiDefSearchBut, with additional operator type and properties,
|
|
|
|
|
* used by callback to call again the right op with the right options (properties values).
|
|
|
|
|
*/
|
2018-07-09 06:38:07 +02:00
|
|
|
uiBut *uiDefSearchButO_ptr(uiBlock *block,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
|
|
|
|
IDProperty *properties,
|
2018-07-09 06:38:07 +02:00
|
|
|
void *arg,
|
|
|
|
|
int retval,
|
|
|
|
|
int icon,
|
2024-07-27 13:20:43 +10:00
|
|
|
int maxncpy,
|
2018-07-09 06:38:07 +02:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
short width,
|
|
|
|
|
short height,
|
|
|
|
|
const char *tip);
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** For #uiDefAutoButsRNA. */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eButLabelAlign {
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Keep current layout for aligning label with property button. */
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
UI_BUT_LABEL_ALIGN_NONE,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Align label and property button vertically. */
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
UI_BUT_LABEL_ALIGN_COLUMN,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Split layout into a column for the label and one for property button. */
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
UI_BUT_LABEL_ALIGN_SPLIT_COLUMN,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Return info for uiDefAutoButsRNA. */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eAutoPropButsReturn {
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Returns when no buttons were added */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_PROP_BUTS_NONE_ADDED = 1 << 0,
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Returned when any property failed the custom check callback (check_prop) */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_PROP_BUTS_ANY_FAILED_CHECK = 1 << 1,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
|
2022-04-02 16:17:48 -05:00
|
|
|
ENUM_OPERATORS(eAutoPropButsReturn, UI_PROP_BUTS_ANY_FAILED_CHECK);
|
|
|
|
|
|
2010-12-03 17:05:21 +00:00
|
|
|
uiBut *uiDefAutoButR(uiBlock *block,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2010-12-03 17:05:21 +00:00
|
|
|
int index,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2010-12-03 17:05:21 +00:00
|
|
|
int icon,
|
2021-03-19 20:22:37 +01:00
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
int width,
|
|
|
|
|
int height);
|
2022-03-15 18:43:26 +01:00
|
|
|
void uiDefAutoButsArrayR(uiBlock *block,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
const int icon,
|
|
|
|
|
const int x,
|
|
|
|
|
const int y,
|
|
|
|
|
const int tot_width,
|
|
|
|
|
const int height);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \a check_prop callback filters functions to avoid drawing certain properties,
|
|
|
|
|
* in cases where PROP_HIDDEN flag can't be used for a property.
|
|
|
|
|
*
|
|
|
|
|
* \param prop_activate_init: Property to activate on initial popup (#UI_BUT_ACTIVATE_ON_INIT).
|
|
|
|
|
*/
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
eAutoPropButsReturn uiDefAutoButsRNA(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
bool (*check_prop)(PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2018-07-26 09:59:56 +10:00
|
|
|
void *user_data),
|
|
|
|
|
void *user_data,
|
2023-08-04 22:15:25 -04:00
|
|
|
PropertyRNA *prop_activate_init,
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
eButLabelAlign label_align,
|
2022-01-07 11:38:08 +11:00
|
|
|
bool compact);
|
2009-02-04 11:52:16 +00:00
|
|
|
|
2022-04-26 22:26:15 +02:00
|
|
|
/**
|
|
|
|
|
* Callback to compare the identity of two buttons, used to identify buttons over redraws. If the
|
|
|
|
|
* callback returns true, the given buttons are considered to be matching and relevant state is
|
|
|
|
|
* preserved (copied from the old to the new button). If it returns false, it's considered
|
|
|
|
|
* non-matching and no further checks are done.
|
|
|
|
|
*
|
|
|
|
|
* If this is set, it is always executed instead of the default comparisons. However it is only
|
|
|
|
|
* executed for buttons that have the same type and the same callback. So callbacks can assume the
|
|
|
|
|
* button types match.
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_func_identity_compare_set(uiBut *but, uiButIdentityCompareFunc cmp_fn);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Public function exported for functions that use #UI_BTYPE_SEARCH_MENU.
|
|
|
|
|
*
|
|
|
|
|
* Use inside searchfunc to add items.
|
|
|
|
|
*
|
|
|
|
|
* \param items: Stores the items.
|
|
|
|
|
* \param name: Text to display for the item.
|
|
|
|
|
* \param poin: Opaque pointer (for use by the caller).
|
|
|
|
|
* \param iconid: The icon, #ICON_NONE for no icon.
|
2022-05-21 00:29:32 +02:00
|
|
|
* \param but_flag: Button flags (#uiBut.flag) indicating the state of the item, typically
|
2022-05-24 11:30:46 +02:00
|
|
|
* #UI_BUT_DISABLED, #UI_BUT_INACTIVE or #UI_BUT_HAS_SEP_CHAR.
|
2022-05-21 00:29:32 +02:00
|
|
|
*
|
2021-12-09 00:55:11 +11:00
|
|
|
* \return false if there is nothing to add.
|
|
|
|
|
*/
|
2020-07-23 17:24:17 +10:00
|
|
|
bool UI_search_item_add(uiSearchItems *items,
|
2025-02-05 18:21:02 -05:00
|
|
|
blender::StringRef name,
|
2020-07-23 17:24:17 +10:00
|
|
|
void *poin,
|
|
|
|
|
int iconid,
|
2022-05-21 00:29:32 +02:00
|
|
|
int but_flag,
|
2022-01-07 11:38:08 +11:00
|
|
|
uint8_t name_prefix_offset);
|
2020-07-23 17:24:17 +10:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \note The item-pointer (referred to below) is a per search item user pointer
|
|
|
|
|
* passed to #UI_search_item_add (stored in #uiSearchItems.pointers).
|
|
|
|
|
*
|
|
|
|
|
* \param search_create_fn: Function to create the menu.
|
|
|
|
|
* \param search_update_fn: Function to refresh search content after the search text has changed.
|
|
|
|
|
* \param arg: user value.
|
|
|
|
|
* \param free_arg: Set to true if the argument is newly allocated memory for every redraw and
|
|
|
|
|
* should be freed when the button is destroyed.
|
|
|
|
|
* \param search_arg_free_fn: When non-null, use this function to free \a arg.
|
|
|
|
|
* \param search_exec_fn: Function that executes the action, gets \a arg as the first argument.
|
|
|
|
|
* The second argument as the active item-pointer
|
|
|
|
|
* \param active: When non-null, this item-pointer item will be visible and selected,
|
|
|
|
|
* otherwise the first item will be selected.
|
|
|
|
|
*/
|
2016-03-02 13:57:16 +11:00
|
|
|
void UI_but_func_search_set(uiBut *but,
|
2020-05-07 23:16:05 +10:00
|
|
|
uiButSearchCreateFn search_create_fn,
|
|
|
|
|
uiButSearchUpdateFn search_update_fn,
|
2019-03-20 19:26:54 +01:00
|
|
|
void *arg,
|
2022-01-07 11:38:08 +11:00
|
|
|
bool free_arg,
|
2021-06-30 17:27:54 +02:00
|
|
|
uiFreeArgFunc search_arg_free_fn,
|
2020-05-08 12:01:35 +10:00
|
|
|
uiButHandleFunc search_exec_fn,
|
2019-03-20 19:26:54 +01:00
|
|
|
void *active);
|
2020-05-07 23:16:22 +10:00
|
|
|
void UI_but_func_search_set_context_menu(uiBut *but, uiButSearchContextMenuFn context_menu_fn);
|
2020-05-11 18:37:43 +10:00
|
|
|
void UI_but_func_search_set_tooltip(uiBut *but, uiButSearchTooltipFn tooltip_fn);
|
2022-09-19 11:57:10 -05:00
|
|
|
void UI_but_func_search_set_listen(uiBut *but, uiButSearchListenFn listen_fn);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \param search_sep_string: when not NULL, this string is used as a separator,
|
|
|
|
|
* showing the icon and highlighted text after the last instance of this string.
|
|
|
|
|
*/
|
2020-05-07 23:16:16 +10:00
|
|
|
void UI_but_func_search_set_sep_string(uiBut *but, const char *search_sep_string);
|
2022-01-07 11:38:08 +11:00
|
|
|
void UI_but_func_search_set_results_are_suggestions(uiBut *but, bool value);
|
2020-05-07 23:16:16 +10:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Height in pixels, it's using hard-coded values still.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_searchbox_size_y();
|
|
|
|
|
int UI_searchbox_size_x();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if a string is in an existing search box.
|
|
|
|
|
*/
|
2024-05-06 09:20:03 +10:00
|
|
|
int UI_search_items_find_index(const uiSearchItems *items, const char *name);
|
2009-06-02 18:10:06 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Adds a hint to the button which draws right aligned, grayed out and never clipped.
|
|
|
|
|
*/
|
2021-06-25 07:57:24 +02:00
|
|
|
void UI_but_hint_drawstr_set(uiBut *but, const char *string);
|
2022-10-20 16:37:07 +02:00
|
|
|
void UI_but_icon_indicator_number_set(uiBut *but, const int indicator_number);
|
2024-04-20 02:50:12 +02:00
|
|
|
void UI_but_icon_indicator_set(uiBut *but, const char *string);
|
|
|
|
|
void UI_but_icon_indicator_color_set(uiBut *but, const uchar color[4]);
|
2021-11-19 17:36:11 -05:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_node_link_set(uiBut *but, bNodeSocket *socket, const float draw_color[4]);
|
2020-04-16 15:09:49 +02:00
|
|
|
|
2020-09-04 21:18:45 +02:00
|
|
|
void UI_but_number_step_size_set(uiBut *but, float step_size);
|
|
|
|
|
void UI_but_number_precision_set(uiBut *but, float precision);
|
|
|
|
|
|
2024-02-01 12:42:25 -05:00
|
|
|
void UI_but_number_slider_step_size_set(uiBut *but, float step_size);
|
|
|
|
|
void UI_but_number_slider_precision_set(uiBut *but, float precision);
|
|
|
|
|
|
2024-03-01 13:46:06 -05:00
|
|
|
void UI_but_label_alpha_factor_set(uiBut *but, float alpha_factor);
|
|
|
|
|
|
2024-02-29 21:49:22 -05:00
|
|
|
void UI_but_search_preview_grid_size_set(uiBut *but, int rows, int cols);
|
|
|
|
|
|
2024-10-01 15:33:15 +02:00
|
|
|
void UI_but_view_item_draw_size_set(uiBut *but,
|
|
|
|
|
const std::optional<int> draw_width = std::nullopt,
|
2024-10-03 12:08:51 +10:00
|
|
|
const std::optional<int> draw_height = std::nullopt);
|
2024-10-01 15:33:15 +02:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_func_handle_set(uiBlock *block, uiBlockHandleFunc func, void *arg);
|
|
|
|
|
void UI_block_func_set(uiBlock *block, uiButHandleFunc func, void *arg1, void *arg2);
|
2024-07-05 17:09:40 +02:00
|
|
|
void UI_block_funcN_set(uiBlock *block,
|
|
|
|
|
uiButHandleNFunc funcN,
|
|
|
|
|
void *argN,
|
|
|
|
|
void *arg2,
|
|
|
|
|
uiButArgNFree func_argN_free_fn = MEM_freeN,
|
|
|
|
|
uiButArgNCopy func_argN_copy_fn = MEM_dupallocN);
|
2009-07-25 13:40:59 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_func_rename_set(uiBut *but, uiButHandleRenameFunc func, void *arg1);
|
Add more control over ID renaming behavior.
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
2024-09-20 13:36:50 +02:00
|
|
|
void UI_but_func_rename_full_set(uiBut *but,
|
|
|
|
|
std::function<void(std::string &new_name)> rename_full_func);
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_func_set(uiBut *but, uiButHandleFunc func, void *arg1, void *arg2);
|
2024-07-05 17:09:40 +02:00
|
|
|
void UI_but_funcN_set(uiBut *but,
|
|
|
|
|
uiButHandleNFunc funcN,
|
|
|
|
|
void *argN,
|
|
|
|
|
void *arg2,
|
|
|
|
|
uiButArgNFree func_argN_free_fn = MEM_freeN,
|
|
|
|
|
uiButArgNCopy func_argN_copy_fn = MEM_dupallocN);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_func_complete_set(uiBut *but, uiButCompleteFunc func, void *arg);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_func_drawextra_set(uiBlock *block,
|
2024-11-01 15:25:24 +01:00
|
|
|
std::function<void(const bContext *C, rcti *rect)> func);
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2015-11-16 06:26:25 +11:00
|
|
|
void UI_but_func_menu_step_set(uiBut *but, uiMenuStepFunc func);
|
|
|
|
|
|
2025-01-06 17:30:47 +01:00
|
|
|
/**
|
|
|
|
|
* When a button displays a menu, hovering another button that can display one will switch to that
|
|
|
|
|
* menu instead. In some cases that's unexpected, so the feature can be disabled here (as in, this
|
|
|
|
|
* button will not spawn its menu on hover and the previously spawned menu will remain open).
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_menu_disable_hover_open(uiBut *but);
|
|
|
|
|
|
2021-06-30 17:27:54 +02:00
|
|
|
void UI_but_func_tooltip_set(uiBut *but, uiButToolTipFunc func, void *arg, uiFreeArgFunc free_arg);
|
2023-09-21 14:49:53 +02:00
|
|
|
/**
|
|
|
|
|
* Enable a custom quick tooltip label. That is, a short tooltip that appears faster than the full
|
|
|
|
|
* one and only shows the label string returned by \a func. After a short delay the full tooltip is
|
|
|
|
|
* shown, including the same label.
|
|
|
|
|
*/
|
2023-07-25 16:22:31 +02:00
|
|
|
void UI_but_func_tooltip_label_set(uiBut *but, std::function<std::string(const uiBut *but)> func);
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2024-01-04 15:07:48 -05:00
|
|
|
enum uiTooltipStyle {
|
2023-09-15 21:06:30 +02:00
|
|
|
UI_TIP_STYLE_NORMAL = 0, /* Regular text. */
|
|
|
|
|
UI_TIP_STYLE_HEADER, /* Header text. */
|
2023-09-17 09:01:43 +10:00
|
|
|
UI_TIP_STYLE_MONO, /* Mono-spaced text. */
|
2023-09-15 21:06:30 +02:00
|
|
|
UI_TIP_STYLE_IMAGE, /* Image field. */
|
2023-10-13 22:34:43 +02:00
|
|
|
UI_TIP_STYLE_SPACER, /* Padding to separate sections. */
|
2024-01-04 15:07:48 -05:00
|
|
|
};
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2024-01-04 15:07:48 -05:00
|
|
|
enum uiTooltipColorID {
|
2023-09-15 21:06:30 +02:00
|
|
|
UI_TIP_LC_MAIN = 0, /* Color of primary text. */
|
|
|
|
|
UI_TIP_LC_VALUE, /* Color for the value of buttons (also shortcuts). */
|
|
|
|
|
UI_TIP_LC_ACTIVE, /* Color of titles of active enum values. */
|
|
|
|
|
UI_TIP_LC_NORMAL, /* Color of regular text. */
|
|
|
|
|
UI_TIP_LC_PYTHON, /* Color of python snippets. */
|
|
|
|
|
UI_TIP_LC_ALERT, /* Warning text color, eg: why operator can't run. */
|
|
|
|
|
UI_TIP_LC_MAX
|
2024-01-04 15:07:48 -05:00
|
|
|
};
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2024-03-18 22:17:45 +01:00
|
|
|
enum class uiTooltipImageBackground {
|
|
|
|
|
None = 0,
|
|
|
|
|
Checkerboard_Themed,
|
|
|
|
|
Checkerboard_Fixed,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct uiTooltipImage {
|
|
|
|
|
ImBuf *ibuf = nullptr;
|
|
|
|
|
short width = 0;
|
|
|
|
|
short height = 0;
|
|
|
|
|
bool premultiplied = false;
|
|
|
|
|
bool border = false;
|
|
|
|
|
bool text_color = false;
|
|
|
|
|
uiTooltipImageBackground background = uiTooltipImageBackground::None;
|
|
|
|
|
};
|
|
|
|
|
|
2023-09-15 21:06:30 +02:00
|
|
|
void UI_but_func_tooltip_custom_set(uiBut *but,
|
|
|
|
|
uiButToolTipCustomFunc func,
|
|
|
|
|
void *arg,
|
|
|
|
|
uiFreeArgFunc free_arg);
|
|
|
|
|
|
2023-09-17 09:01:45 +10:00
|
|
|
/**
|
|
|
|
|
* \param text: Allocated text (transfer ownership to `data`) or null.
|
|
|
|
|
* \param suffix: Allocated text (transfer ownership to `data`) or null.
|
|
|
|
|
*/
|
2024-07-26 12:24:33 +02:00
|
|
|
void UI_tooltip_text_field_add(uiTooltipData &data,
|
2024-01-19 09:05:35 -05:00
|
|
|
std::string text,
|
|
|
|
|
std::string suffix,
|
2023-09-17 09:01:45 +10:00
|
|
|
const uiTooltipStyle style,
|
|
|
|
|
const uiTooltipColorID color_id,
|
2024-01-19 09:05:35 -05:00
|
|
|
const bool is_pad = false);
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2023-09-17 09:01:45 +10:00
|
|
|
/**
|
|
|
|
|
* \param image: Image buffer (duplicated, ownership is *not* transferred to `data`).
|
2023-09-17 11:32:41 +10:00
|
|
|
* \param image_size: Display size for the image (pixels without UI scale applied).
|
2023-09-17 09:01:45 +10:00
|
|
|
*/
|
2024-07-26 12:24:33 +02:00
|
|
|
void UI_tooltip_image_field_add(uiTooltipData &data, const uiTooltipImage &image_data);
|
2023-09-15 21:06:30 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Recreate tool-tip (use to update dynamic tips)
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_tooltip_refresh(bContext *C, uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Removes tool-tip timer from active but
|
|
|
|
|
* (meaning tool-tip is disabled until it's re-enabled again).
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_tooltip_timer_remove(bContext *C, uiBut *but);
|
2015-02-11 00:06:03 +01:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_textbutton_activate_rna(const bContext *C,
|
|
|
|
|
ARegion *region,
|
2018-07-09 06:38:07 +02:00
|
|
|
const void *rna_poin_data,
|
|
|
|
|
const char *rna_prop_id);
|
2024-07-27 13:20:43 +10:00
|
|
|
bool UI_textbutton_activate_but(const bContext *C, uiBut *actbut);
|
2013-03-24 13:43:40 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* push a new event onto event queue to activate the given button
|
|
|
|
|
* (usually a text-field) upon entering a popup
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_focus_on_enter_event(wmWindow *win, uiBut *but);
|
2011-02-15 01:24:12 +00:00
|
|
|
|
2017-11-02 04:30:07 +11:00
|
|
|
void UI_but_func_hold_set(uiBut *but, uiButHandleHoldFunc func, void *argN);
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *UI_but_extra_operator_icon_add(uiBut *but,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorCallContext opcontext,
|
|
|
|
|
int icon);
|
2024-01-18 23:12:09 -05:00
|
|
|
wmOperatorType *UI_but_extra_operator_icon_optype_get(const uiButExtraOpIcon *extra_icon);
|
|
|
|
|
PointerRNA *UI_but_extra_operator_icon_opptr_get(const uiButExtraOpIcon *extra_icon);
|
2019-09-09 16:34:16 +02:00
|
|
|
|
2022-06-16 11:29:20 +02:00
|
|
|
/**
|
2023-08-03 16:54:39 +02:00
|
|
|
* Get the scaled size for a preview button (typically #UI_BTyPE_PREVIEW_TILE) based on \a
|
|
|
|
|
* size_px plus padding.
|
2022-06-16 11:29:20 +02:00
|
|
|
*/
|
2023-12-30 23:12:42 -05:00
|
|
|
int UI_preview_tile_size_x(const int size_px = 96);
|
|
|
|
|
int UI_preview_tile_size_y(const int size_px = 96);
|
|
|
|
|
int UI_preview_tile_size_y_no_label(const int size_px = 96);
|
2022-06-16 11:29:20 +02:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Autocomplete
|
|
|
|
|
*
|
|
|
|
|
* Tab complete helper functions, for use in uiButCompleteFunc callbacks.
|
|
|
|
|
* Call begin once, then multiple times do_name with all possibilities,
|
|
|
|
|
* and finally end to finish and get the completed name. */
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
struct AutoComplete;
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2013-11-19 16:31:48 +01:00
|
|
|
#define AUTOCOMPLETE_NO_MATCH 0
|
|
|
|
|
#define AUTOCOMPLETE_FULL_MATCH 1
|
|
|
|
|
#define AUTOCOMPLETE_PARTIAL_MATCH 2
|
|
|
|
|
|
2024-07-27 13:20:43 +10:00
|
|
|
AutoComplete *UI_autocomplete_begin(const char *startname, size_t maxncpy);
|
2025-02-05 18:21:02 -05:00
|
|
|
void UI_autocomplete_update_name(AutoComplete *autocpl, blender::StringRef name);
|
2014-11-09 21:20:40 +01:00
|
|
|
int UI_autocomplete_end(AutoComplete *autocpl, char *autoname);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
|
2022-05-31 15:06:57 +02:00
|
|
|
/* Button drag-data (interface_drag.cc).
|
|
|
|
|
*
|
|
|
|
|
* Functions to set drag data for buttons. This enables dragging support, whereby the drag data is
|
|
|
|
|
* "dragged", not the button itself. */
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_drag_set_id(uiBut *but, ID *id);
|
2022-05-31 15:06:57 +02:00
|
|
|
/**
|
|
|
|
|
* Set an image to display while dragging. This works for any drag type (`WM_DRAG_XXX`).
|
|
|
|
|
* Not to be confused with #UI_but_drag_set_image(), which sets up dragging of an image.
|
2023-02-20 11:51:16 +01:00
|
|
|
*
|
|
|
|
|
* Sets #UI_BUT_DRAG_FULL_BUT so the full button can be dragged.
|
2022-05-31 15:06:57 +02:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_drag_attach_image(uiBut *but, const ImBuf *imb, float scale);
|
2023-07-04 14:46:19 +02:00
|
|
|
|
2022-05-31 15:06:57 +02:00
|
|
|
/**
|
2023-02-20 11:51:16 +01:00
|
|
|
* Sets #UI_BUT_DRAG_FULL_BUT so the full button can be dragged.
|
2022-05-31 15:06:57 +02:00
|
|
|
* \param asset: May be passed from a temporary variable, drag data only stores a copy of this.
|
2025-01-24 22:32:27 +01:00
|
|
|
* \param icon: Small icon that will be drawn while dragging.
|
|
|
|
|
* \param preview_icon: Bigger preview size icon that will be drawn while dragging instead of \a
|
|
|
|
|
* icon.
|
2022-05-31 15:06:57 +02:00
|
|
|
*/
|
|
|
|
|
void UI_but_drag_set_asset(uiBut *but,
|
2023-07-04 14:46:19 +02:00
|
|
|
const blender::asset_system::AssetRepresentation *asset,
|
2023-09-26 16:20:49 +02:00
|
|
|
int import_method, /* eAssetImportMethod */
|
2022-05-31 15:06:57 +02:00
|
|
|
int icon,
|
2025-01-24 22:32:27 +01:00
|
|
|
int preview_icon);
|
2023-07-04 14:46:19 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_drag_set_rna(uiBut *but, PointerRNA *ptr);
|
2023-02-27 16:31:31 +01:00
|
|
|
/**
|
|
|
|
|
* Enable dragging a path from this button.
|
|
|
|
|
* \param path: The path to drag. The passed string may be destructed, button keeps a copy.
|
|
|
|
|
*/
|
|
|
|
|
void UI_but_drag_set_path(uiBut *but, const char *path);
|
2022-05-31 15:06:57 +02:00
|
|
|
void UI_but_drag_set_name(uiBut *but, const char *name);
|
2023-02-20 11:51:16 +01:00
|
|
|
|
2023-02-27 16:31:31 +01:00
|
|
|
/**
|
|
|
|
|
* Sets #UI_BUT_DRAG_FULL_BUT so the full button can be dragged.
|
|
|
|
|
* \param path: The path to drag. The passed string may be destructed, button keeps a copy.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_drag_set_image(uiBut *but, const char *path, int icon, const ImBuf *imb, float scale);
|
2022-05-31 15:06:57 +02:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Panels
|
|
|
|
|
*
|
|
|
|
|
* Functions for creating, freeing and drawing panels. The API here
|
|
|
|
|
* could use a good cleanup, though how they will function in 2.5 is
|
|
|
|
|
* not clear yet so we postpone that. */
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panels_begin(const bContext *C, ARegion *region);
|
|
|
|
|
void UI_panels_end(const bContext *C, ARegion *region, int *r_x, int *r_y);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draw panels, selected (panels currently being dragged) on top.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panels_draw(const bContext *C, ARegion *region);
|
2009-04-16 21:39:45 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
Panel *UI_panel_find_by_type(ListBase *lb, const PanelType *pt);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \note \a panel should be return value from #UI_panel_find_by_type and can be NULL.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
Panel *UI_panel_begin(
|
|
|
|
|
ARegion *region, ListBase *lb, uiBlock *block, PanelType *pt, Panel *panel, bool *r_open);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Create the panel header button group, used to mark which buttons are part of
|
|
|
|
|
* panel headers for the panel search process that happens later. This Should be
|
|
|
|
|
* called before adding buttons for the panel's header layout.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_header_buttons_begin(Panel *panel);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Finish the button group for the panel header to avoid putting panel body buttons in it.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_header_buttons_end(Panel *panel);
|
|
|
|
|
void UI_panel_end(Panel *panel, int width, int height);
|
2020-05-26 15:39:49 -04:00
|
|
|
|
2023-09-12 14:47:46 +02:00
|
|
|
/** Set the name that should be drawn in the UI. Should be a translated string. */
|
|
|
|
|
void UI_panel_drawname_set(Panel *panel, blender::StringRef name);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Set a context for this entire panel and its current layout. This should be used whenever panel
|
|
|
|
|
* callbacks that are called outside of regular drawing might require context. Currently it affects
|
|
|
|
|
* the #PanelType.reorder callback only.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_context_pointer_set(Panel *panel, const char *name, PointerRNA *ptr);
|
2021-11-23 18:32:23 +01:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Get the panel's expansion state, taking into account
|
|
|
|
|
* expansion set from property search if it applies.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_panel_is_closed(const Panel *panel);
|
|
|
|
|
bool UI_panel_is_active(const Panel *panel);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For button layout next to label.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_label_offset(const uiBlock *block, int *r_x, int *r_y);
|
|
|
|
|
bool UI_panel_should_show_background(const ARegion *region, const PanelType *panel_type);
|
|
|
|
|
int UI_panel_size_y(const Panel *panel);
|
|
|
|
|
bool UI_panel_is_dragging(const Panel *panel);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Find whether a panel or any of its sub-panels contain a property that matches the search filter,
|
|
|
|
|
* depending on the search process running in #UI_block_apply_search_filter earlier.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_panel_matches_search_filter(const Panel *panel);
|
|
|
|
|
bool UI_panel_can_be_pinned(const Panel *panel);
|
2009-04-02 01:39:33 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_panel_category_is_visible(const ARegion *region);
|
|
|
|
|
void UI_panel_category_add(ARegion *region, const char *name);
|
|
|
|
|
PanelCategoryDyn *UI_panel_category_find(const ARegion *region, const char *idname);
|
2023-10-23 19:07:07 +02:00
|
|
|
int UI_panel_category_index_find(ARegion *region, const char *idname);
|
2023-08-04 22:15:25 -04:00
|
|
|
PanelCategoryStack *UI_panel_category_active_find(ARegion *region, const char *idname);
|
|
|
|
|
const char *UI_panel_category_active_get(ARegion *region, bool set_fallback);
|
|
|
|
|
void UI_panel_category_active_set(ARegion *region, const char *idname);
|
2023-10-23 19:07:07 +02:00
|
|
|
/** \param index: index of item _in #ARegion.panels_category list_. */
|
|
|
|
|
void UI_panel_category_index_active_set(ARegion *region, const int index);
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_category_active_set_default(ARegion *region, const char *idname);
|
|
|
|
|
void UI_panel_category_clear_all(ARegion *region);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draw vertical tabs on the left side of the region, one tab per category.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panel_category_draw_all(ARegion *region, const char *category_id_active);
|
2013-12-17 03:21:55 +11:00
|
|
|
|
2025-01-14 19:43:42 +01:00
|
|
|
void UI_panel_stop_animation(const bContext *C, Panel *panel);
|
|
|
|
|
|
2020-09-02 14:13:26 -05:00
|
|
|
/* Panel custom data. */
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *UI_panel_custom_data_get(const Panel *panel);
|
|
|
|
|
PointerRNA *UI_region_panel_custom_data_under_cursor(const bContext *C, const wmEvent *event);
|
|
|
|
|
void UI_panel_custom_data_set(Panel *panel, PointerRNA *custom_data);
|
2020-06-29 15:00:25 -04:00
|
|
|
|
2022-06-03 13:39:37 +10:00
|
|
|
/* Poly-instantiated panels for representing a list of data. */
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Called in situations where panels need to be added dynamically rather than
|
|
|
|
|
* having only one panel corresponding to each #PanelType.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
Panel *UI_panel_add_instanced(const bContext *C,
|
|
|
|
|
ARegion *region,
|
|
|
|
|
ListBase *panels,
|
|
|
|
|
const char *panel_idname,
|
|
|
|
|
PointerRNA *custom_data);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Remove instanced panels from the region's panel list.
|
|
|
|
|
*
|
|
|
|
|
* \note Can be called with NULL \a C, but it should be avoided because
|
|
|
|
|
* handlers might not be removed.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_panels_free_instanced(const bContext *C, ARegion *region);
|
2020-05-26 15:39:49 -04:00
|
|
|
|
2023-06-26 10:09:57 +10:00
|
|
|
#define INSTANCED_PANEL_UNIQUE_STR_SIZE 16
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Find a unique key to append to the #PanelType.idname for the lookup to the panel's #uiBlock.
|
|
|
|
|
* Needed for instanced panels, where there can be multiple with the same type and identifier.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_list_panel_unique_str(Panel *panel, char *r_name);
|
2020-05-26 15:39:49 -04:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
using uiListPanelIDFromDataFunc = void (*)(void *data_link, char *r_idname);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the instanced panels in the region's panels correspond to the list of data the panels
|
|
|
|
|
* represent. Returns false if the panels have been reordered or if the types from the list data
|
|
|
|
|
* don't match in any way.
|
|
|
|
|
*
|
|
|
|
|
* \param data: The list of data to check against the instanced panels.
|
|
|
|
|
* \param panel_idname_func: Function to find the #PanelType.idname for each item in the data list.
|
|
|
|
|
* For a readability and generality, this lookup happens separately for each type of panel list.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_panel_list_matches_data(ARegion *region,
|
|
|
|
|
ListBase *data,
|
2020-05-26 15:39:49 -04:00
|
|
|
uiListPanelIDFromDataFunc panel_idname_func);
|
|
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Handlers
|
|
|
|
|
*
|
|
|
|
|
* Handlers that can be registered in regions, areas and windows for
|
|
|
|
|
* handling WM events. Mostly this is done automatic by modules such
|
|
|
|
|
* as screen/ if ED_KEYMAP_UI is set, or internally in popup functions. */
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_region_handlers_add(ListBase *handlers);
|
|
|
|
|
void UI_popup_handlers_add(bContext *C, ListBase *handlers, uiPopupBlockHandle *popup, char flag);
|
|
|
|
|
void UI_popup_handlers_remove(ListBase *handlers, uiPopupBlockHandle *popup);
|
|
|
|
|
void UI_popup_handlers_remove_all(bContext *C, ListBase *handlers);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
/* Module
|
|
|
|
|
*
|
|
|
|
|
* init and exit should be called before using this module. init_userdef must
|
|
|
|
|
* be used to reinitialize some internal state if user preferences change. */
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_init();
|
2021-12-09 00:55:11 +11:00
|
|
|
/* after reading userdef file */
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_init_userdef();
|
|
|
|
|
void UI_reinit_font();
|
|
|
|
|
void UI_exit();
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2024-07-03 18:02:20 +02:00
|
|
|
/* When changing UI font, update text style weights with default font weight
|
|
|
|
|
* if non-variable. Therefore fixed weight bold font will look bold. */
|
|
|
|
|
void UI_update_text_styles();
|
|
|
|
|
|
2009-03-13 13:38:41 +00:00
|
|
|
/* Layout
|
|
|
|
|
*
|
|
|
|
|
* More automated layout of buttons. Has three levels:
|
|
|
|
|
* - Layout: contains a number templates, within a bounded width or height.
|
|
|
|
|
* - Template: predefined layouts for buttons with a number of slots, each
|
|
|
|
|
* slot can contain multiple items.
|
|
|
|
|
* - Item: item to put in a template slot, being either an RNA property,
|
UI: Layout Engine
* Buttons are now created first, and after that the layout is computed.
This means the layout engine now works at button level, and makes it
easier to write templates. Otherwise you had to store all info and
create the buttons later.
* Added interface_templates.c as a separate file to put templates in.
These can contain regular buttons, and can be put in a Free layout,
which means you can specify manual coordinates, but still get nested
correct inside other layouts.
* API was changed to allow better nesting. Previously items were added
in the last added layout specifier, i.e. one level up in the layout
hierarchy. This doesn't work well in always, so now when creating things
like rows or columns it always returns a layout which you have to add
the items in. All py scripts were updated to follow this.
* Computing the layout now goes in two passes, first estimating the
required width/height of all nested layouts, and then in the second
pass using the results of that to decide on the actual locations.
* Enum and array buttons now follow the direction of the layout, i.e.
they are vertical or horizontal depending if they are in a column or row.
* Color properties now get a color picker, and only get the additional
RGB sliders with Expand=True.
* File/directory string properties now get a button next to them for
opening the file browse, though this is not implemented yet.
* Layout items can now be aligned, set align=True when creating a column,
row, etc.
* Buttons now get a minimum width of one icon (avoids squashing icon
buttons).
* Moved some more space variables into Style.
2009-05-15 11:19:59 +00:00
|
|
|
* operator, label or menu. Also regular buttons can be used when setting
|
|
|
|
|
* uiBlockCurLayout. */
|
2009-03-13 13:38:41 +00:00
|
|
|
|
|
|
|
|
/* layout */
|
2019-01-14 15:58:40 +11:00
|
|
|
enum {
|
|
|
|
|
UI_LAYOUT_HORIZONTAL = 0,
|
|
|
|
|
UI_LAYOUT_VERTICAL = 1,
|
|
|
|
|
};
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
enum {
|
|
|
|
|
UI_LAYOUT_PANEL = 0,
|
|
|
|
|
UI_LAYOUT_HEADER = 1,
|
|
|
|
|
UI_LAYOUT_MENU = 2,
|
|
|
|
|
UI_LAYOUT_TOOLBAR = 3,
|
|
|
|
|
UI_LAYOUT_PIEMENU = 4,
|
|
|
|
|
UI_LAYOUT_VERT_BAR = 5,
|
|
|
|
|
};
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2013-12-24 17:20:37 +11:00
|
|
|
#define UI_UNIT_X ((void)0, U.widget_unit)
|
|
|
|
|
#define UI_UNIT_Y ((void)0, U.widget_unit)
|
2012-05-12 20:39:39 +00:00
|
|
|
|
2019-01-14 15:58:40 +11:00
|
|
|
enum {
|
|
|
|
|
UI_LAYOUT_ALIGN_EXPAND = 0,
|
|
|
|
|
UI_LAYOUT_ALIGN_LEFT = 1,
|
|
|
|
|
UI_LAYOUT_ALIGN_CENTER = 2,
|
|
|
|
|
UI_LAYOUT_ALIGN_RIGHT = 3,
|
|
|
|
|
};
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eUI_Item_Flag {
|
2020-02-20 10:21:23 +11:00
|
|
|
/* UI_ITEM_O_RETURN_PROPS = 1 << 0, */ /* UNUSED */
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_ITEM_R_EXPAND = 1 << 1,
|
|
|
|
|
UI_ITEM_R_SLIDER = 1 << 2,
|
2019-05-21 14:39:09 +10:00
|
|
|
/**
|
|
|
|
|
* Use for booleans, causes the button to draw with an outline (emboss),
|
|
|
|
|
* instead of text with a checkbox.
|
|
|
|
|
* This is implied when toggle buttons have an icon
|
|
|
|
|
* unless #UI_ITEM_R_ICON_NEVER flag is set.
|
|
|
|
|
*/
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_ITEM_R_TOGGLE = 1 << 3,
|
2019-05-21 14:39:09 +10:00
|
|
|
/**
|
|
|
|
|
* Don't attempt to use an icon when the icon is set to #ICON_NONE.
|
|
|
|
|
*
|
2023-08-05 13:46:22 +10:00
|
|
|
* Use for booleans, causes the buttons to always show as a checkbox
|
2019-05-21 14:39:09 +10:00
|
|
|
* even when there is an icon (which would normally show the button as a toggle).
|
|
|
|
|
*/
|
|
|
|
|
UI_ITEM_R_ICON_NEVER = 1 << 4,
|
|
|
|
|
UI_ITEM_R_ICON_ONLY = 1 << 5,
|
|
|
|
|
UI_ITEM_R_EVENT = 1 << 6,
|
|
|
|
|
UI_ITEM_R_FULL_EVENT = 1 << 7,
|
|
|
|
|
UI_ITEM_R_NO_BG = 1 << 8,
|
|
|
|
|
UI_ITEM_R_IMMEDIATE = 1 << 9,
|
|
|
|
|
UI_ITEM_O_DEPRESS = 1 << 10,
|
|
|
|
|
UI_ITEM_R_COMPACT = 1 << 11,
|
|
|
|
|
UI_ITEM_R_CHECKBOX_INVERT = 1 << 12,
|
UI: Better split layout support for checkboxes
Makes the following layout changes possible:
{F8473498} {F8473499} {F8473502}
The next commit will contain many layout changes to make good use of
these new possibilities. The result should be more consistent, easier to
read and should give a more organized impression. Additionally, it
should be possible to replace many sub-panels with compacter layouts.
Main changes:
* Checkboxes now respect the property split layouts
* Add support for row and column headers (i.e.
`uiLayout.column(heading="Foo")`, `uiLayout.row(heading="Bar")`). If the
first property added to this layout doesn't insert anything into the label
split column, the heading is inserted there. Otherwise, it's inserted as own
item.
* Add support for manually inserting decorators for an existing item
(`uiLayout.prop_decorator()`). That way layout creators can manually insert
this, which was the only way I saw to support property split layouts with a
checkbox before the actual property. {F8471883}
* Autogenerated layouts for operator properties look bad if there are only
checkboxes (which only use half the region width). So before creating the
layout, we iterate over visible properties and disable split layout if all
are booleans. I think this is fine, if needed we could also add layout hints
to operators.
* `uiTemplateOperatorPropertyButs()` now handles macros itself, the caller
used to be responsible for this. Code that didn't handle these so far never
used macros I think, so this change should be invisible.
* Remove manual property split layout from autogenerated operator properties
layout.
* Padding of checkboxes is tweaked to make their label visually more connected
to the checkboxes.
* Support split layout for menus (should work for `uiLayout.menu()`,
`.operator_menu_enum()`, `.prop_menu_enum()`, maybe more)
Maniphest Task: https://developer.blender.org/T65965
Differential Revision: https://developer.blender.org/D7427
Reviewed by: Brecht Van Lommel, William Reynish, Pablo Vazques
2020-04-17 16:40:25 +02:00
|
|
|
/** Don't add a real decorator item, just blank space. */
|
|
|
|
|
UI_ITEM_R_FORCE_BLANK_DECORATE = 1 << 13,
|
2020-04-27 15:24:25 +02:00
|
|
|
/* Even create the property split layout if there's no name to show there. */
|
|
|
|
|
UI_ITEM_R_SPLIT_EMPTY_NAME = 1 << 14,
|
UI: Support semi-modal text input while other UI stays interactive
Adds support for text buttons that capture text input, while the rest of the
UI stays interactive. This is useful for example for filter buttons in popups
that are used for searching. Current search popups are an ad-hoc implementation
that doesn't use the normal widget system (and thus are quite limited).
For the brush assets project this is important to allow quickly popping up the
brush asset shelf popup, immediately typing to search a brush, and activating
a brush with a single click (rather than having to confirm text input first).
All UI elements stay interactive with hover feedback, changing asset library
and catalogs is possible, tooltips and context menus can be opened, and any
text input is still sent to the search button.
Normal search popups already keep their search results interactive like this
during text input, but are too limited because they don't use our widget
system. For example custom layouts are not possible with them. With this
feature implemented, we could consider rewriting them to use the widget
system, removing the ad-hoc implementation.
Part of the brush assets project, see:
- https://projects.blender.org/blender/blender/issues/116337
- https://projects.blender.org/blender/blender/pulls/106303
Initially reviewed in:
https://projects.blender.org/blender/blender/pulls/122871
2024-07-06 12:22:16 +02:00
|
|
|
/**
|
|
|
|
|
* Only for text buttons (for now): Force the button as active in a semi-modal state (capturing
|
|
|
|
|
* text input while leaving the remaining UI interactive).
|
|
|
|
|
*/
|
|
|
|
|
UI_ITEM_R_TEXT_BUT_FORCE_SEMI_MODAL_ACTIVE = 1 << 15,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
UI: Support semi-modal text input while other UI stays interactive
Adds support for text buttons that capture text input, while the rest of the
UI stays interactive. This is useful for example for filter buttons in popups
that are used for searching. Current search popups are an ad-hoc implementation
that doesn't use the normal widget system (and thus are quite limited).
For the brush assets project this is important to allow quickly popping up the
brush asset shelf popup, immediately typing to search a brush, and activating
a brush with a single click (rather than having to confirm text input first).
All UI elements stay interactive with hover feedback, changing asset library
and catalogs is possible, tooltips and context menus can be opened, and any
text input is still sent to the search button.
Normal search popups already keep their search results interactive like this
during text input, but are too limited because they don't use our widget
system. For example custom layouts are not possible with them. With this
feature implemented, we could consider rewriting them to use the widget
system, removing the ad-hoc implementation.
Part of the brush assets project, see:
- https://projects.blender.org/blender/blender/issues/116337
- https://projects.blender.org/blender/blender/pulls/106303
Initially reviewed in:
https://projects.blender.org/blender/blender/pulls/122871
2024-07-06 12:22:16 +02:00
|
|
|
ENUM_OPERATORS(eUI_Item_Flag, UI_ITEM_R_TEXT_BUT_FORCE_SEMI_MODAL_ACTIVE)
|
2023-07-29 15:06:33 +10:00
|
|
|
#define UI_ITEM_NONE eUI_Item_Flag(0)
|
2009-08-21 12:57:47 +00:00
|
|
|
|
2018-11-20 13:37:31 +01:00
|
|
|
#define UI_HEADER_OFFSET ((void)0, 0.4f * UI_UNIT_X)
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
|
|
|
|
|
/* uiLayoutOperatorButs flags */
|
|
|
|
|
enum {
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_TEMPLATE_OP_PROPS_SHOW_TITLE = 1 << 0,
|
|
|
|
|
UI_TEMPLATE_OP_PROPS_SHOW_EMPTY = 1 << 1,
|
|
|
|
|
UI_TEMPLATE_OP_PROPS_COMPACT = 1 << 2,
|
|
|
|
|
UI_TEMPLATE_OP_PROPS_HIDE_ADVANCED = 1 << 3,
|
UI: Better split layout support for checkboxes
Makes the following layout changes possible:
{F8473498} {F8473499} {F8473502}
The next commit will contain many layout changes to make good use of
these new possibilities. The result should be more consistent, easier to
read and should give a more organized impression. Additionally, it
should be possible to replace many sub-panels with compacter layouts.
Main changes:
* Checkboxes now respect the property split layouts
* Add support for row and column headers (i.e.
`uiLayout.column(heading="Foo")`, `uiLayout.row(heading="Bar")`). If the
first property added to this layout doesn't insert anything into the label
split column, the heading is inserted there. Otherwise, it's inserted as own
item.
* Add support for manually inserting decorators for an existing item
(`uiLayout.prop_decorator()`). That way layout creators can manually insert
this, which was the only way I saw to support property split layouts with a
checkbox before the actual property. {F8471883}
* Autogenerated layouts for operator properties look bad if there are only
checkboxes (which only use half the region width). So before creating the
layout, we iterate over visible properties and disable split layout if all
are booleans. I think this is fine, if needed we could also add layout hints
to operators.
* `uiTemplateOperatorPropertyButs()` now handles macros itself, the caller
used to be responsible for this. Code that didn't handle these so far never
used macros I think, so this change should be invisible.
* Remove manual property split layout from autogenerated operator properties
layout.
* Padding of checkboxes is tweaked to make their label visually more connected
to the checkboxes.
* Support split layout for menus (should work for `uiLayout.menu()`,
`.operator_menu_enum()`, `.prop_menu_enum()`, maybe more)
Maniphest Task: https://developer.blender.org/T65965
Differential Revision: https://developer.blender.org/D7427
Reviewed by: Brecht Van Lommel, William Reynish, Pablo Vazques
2020-04-17 16:40:25 +02:00
|
|
|
/* Disable property split for the default layout (custom ui callbacks still have full control
|
|
|
|
|
* over the layout and can enable it). */
|
|
|
|
|
UI_TEMPLATE_OP_PROPS_NO_SPLIT_LAYOUT = 1 << 4,
|
2024-04-16 15:02:33 +02:00
|
|
|
UI_TEMPLATE_OP_PROPS_HIDE_PRESETS = 1 << 5,
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
};
|
2010-12-15 05:42:23 +00:00
|
|
|
|
2023-01-20 15:20:02 +11:00
|
|
|
/* Used for transparent checkers shown under color buttons that have an alpha component. */
|
2013-12-24 17:20:37 +11:00
|
|
|
#define UI_ALPHA_CHECKER_DARK 100
|
|
|
|
|
#define UI_ALPHA_CHECKER_LIGHT 160
|
|
|
|
|
|
2011-09-11 06:41:09 +00:00
|
|
|
/* flags to set which corners will become rounded:
|
|
|
|
|
*
|
|
|
|
|
* 1------2
|
|
|
|
|
* | |
|
|
|
|
|
* 8------4 */
|
|
|
|
|
|
|
|
|
|
enum {
|
2019-01-14 15:58:40 +11:00
|
|
|
UI_CNR_TOP_LEFT = 1 << 0,
|
|
|
|
|
UI_CNR_TOP_RIGHT = 1 << 1,
|
|
|
|
|
UI_CNR_BOTTOM_RIGHT = 1 << 2,
|
|
|
|
|
UI_CNR_BOTTOM_LEFT = 1 << 3,
|
2011-09-11 06:41:09 +00:00
|
|
|
/* just for convenience */
|
2013-06-25 10:30:07 +00:00
|
|
|
UI_CNR_NONE = 0,
|
2019-01-15 23:57:49 +11:00
|
|
|
UI_CNR_ALL = (UI_CNR_TOP_LEFT | UI_CNR_TOP_RIGHT | UI_CNR_BOTTOM_RIGHT | UI_CNR_BOTTOM_LEFT),
|
2011-09-11 06:41:09 +00:00
|
|
|
};
|
|
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
uiLayout *UI_block_layout(uiBlock *block,
|
|
|
|
|
int dir,
|
|
|
|
|
int type,
|
|
|
|
|
int x,
|
|
|
|
|
int y,
|
|
|
|
|
int size,
|
|
|
|
|
int em,
|
|
|
|
|
int padding,
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiStyle *style);
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_block_layout_set_current(uiBlock *block, uiLayout *layout);
|
2019-03-25 12:19:55 +11:00
|
|
|
void UI_block_layout_resolve(uiBlock *block, int *r_x, int *r_y);
|
2022-01-03 19:20:00 +01:00
|
|
|
bool UI_block_layout_needs_resolving(const uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for property search when the layout process needs to be cancelled in order to avoid
|
|
|
|
|
* computing the locations for buttons, but the layout items created while adding the buttons
|
|
|
|
|
* must still be freed.
|
|
|
|
|
*/
|
2020-10-13 13:10:41 -05:00
|
|
|
void UI_block_layout_free(uiBlock *block);
|
2009-03-13 13:38:41 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Apply property search behavior, setting panel flags and deactivating buttons that don't match.
|
|
|
|
|
*
|
|
|
|
|
* \note Must not be run after #UI_block_layout_resolve.
|
|
|
|
|
*/
|
2020-09-24 11:22:30 -05:00
|
|
|
bool UI_block_apply_search_filter(uiBlock *block, const char *search_filter);
|
2020-09-15 11:25:49 -05:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_region_message_subscribe(ARegion *region, wmMsgBus *mbus);
|
2017-11-13 19:43:34 +11:00
|
|
|
|
2009-05-28 23:37:55 +00:00
|
|
|
uiBlock *uiLayoutGetBlock(uiLayout *layout);
|
2009-04-22 18:39:44 +00:00
|
|
|
|
2009-05-28 23:37:55 +00:00
|
|
|
void uiLayoutSetFunc(uiLayout *layout, uiMenuHandleFunc handlefunc, void *argv);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiLayoutSetContextPointer(uiLayout *layout, blender::StringRef name, PointerRNA *ptr);
|
|
|
|
|
void uiLayoutSetContextString(uiLayout *layout, blender::StringRef name, blender::StringRef value);
|
2024-12-10 14:49:11 +01:00
|
|
|
void uiLayoutSetContextInt(uiLayout *layout, blender::StringRef name, int64_t value);
|
2023-08-04 22:15:25 -04:00
|
|
|
bContextStore *uiLayoutGetContextStore(uiLayout *layout);
|
2023-08-31 11:59:58 -04:00
|
|
|
void uiLayoutContextCopy(uiLayout *layout, const bContextStore *context);
|
UI: Add support for showing socket descriptions in tooltips
Currently, hovering over a socket itself shows no tooltip at all, while
hovering over its value field shows "Default value", which is not helpful.
This patch therefore implements socket tooltips following the proposal at
https://blender.community/c/rightclickselect/2Qgbbc/.
A lot of the basic functionality was already implemented for Geometry Nodes,
where hovering over the socket itself shows introspection info.
This patch extends this by:
- Supporting dynamic tooltips on labels, which is important for good tooltip
coverage in a socket's region of the node.
- Adding a function to setting a dynamic tooltip for an entire uiLayout, which
avoids needing to set it manually for a wide variety of socket types.
- Hiding the property label field in a tooltip when dynamic tooltip is also
provided. If really needed, this label can be restored through the dynamic
tooltip, but in all current cases the label is actually pointless anyways
since the dynamic tooltip gives more accurate and specific information.
- Adding dynamic tooltips to a socket's UI layout row if it has a description
configured, both in the Node Editor as well as in the Material Properties.
Note that the patch does not add any actual tooltip content yet, just the
infrastructure to show them. By default, sockets without a description still
show the old "Default value" tooltip.
For an example of how to add socket descriptions, check the Cylinder node
in the Geometry Nodes.
Differential Revision: https://developer.blender.org/D9967
2022-04-11 02:02:12 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set tooltip function for all buttons in the layout.
|
|
|
|
|
* func, arg and free_arg are passed on to UI_but_func_tooltip_set, so their meaning is the same.
|
|
|
|
|
*
|
|
|
|
|
* \param func: The callback function that gets called to get tooltip content
|
|
|
|
|
* \param arg: An optional opaque pointer that gets passed to func
|
|
|
|
|
* \param free_arg: An optional callback for freeing arg (can be set to e.g. MEM_freeN)
|
|
|
|
|
* \param copy_arg: An optional callback for duplicating arg in case UI_but_func_tooltip_set
|
|
|
|
|
* is being called on multiple buttons (can be set to e.g. MEM_dupallocN). If set to NULL, arg will
|
|
|
|
|
* be passed as-is to all buttons.
|
|
|
|
|
*/
|
|
|
|
|
void uiLayoutSetTooltipFunc(uiLayout *layout,
|
|
|
|
|
uiButToolTipFunc func,
|
|
|
|
|
void *arg,
|
|
|
|
|
uiCopyArgFunc copy_arg,
|
|
|
|
|
uiFreeArgFunc free_arg);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This is a bit of a hack but best keep it in one place at least.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *UI_but_operatortype_get_from_enum_menu(uiBut *but, PropertyRNA **r_prop);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This is a bit of a hack but best keep it in one place at least.
|
|
|
|
|
*/
|
2024-01-18 23:12:09 -05:00
|
|
|
MenuType *UI_but_menutype_get(const uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This is a bit of a hack but best keep it in one place at least.
|
|
|
|
|
*/
|
2024-01-18 23:12:09 -05:00
|
|
|
PanelType *UI_but_paneltype_get(const uiBut *but);
|
2024-07-07 20:00:35 +02:00
|
|
|
/**
|
|
|
|
|
* This is a bit of a hack but best keep it in one place at least.
|
|
|
|
|
*/
|
|
|
|
|
std::optional<blender::StringRefNull> UI_but_asset_shelf_type_idname_get(const uiBut *but);
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_menutype_draw(bContext *C, MenuType *mt, uiLayout *layout);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Used for popup panels only.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_paneltype_draw(bContext *C, PanelType *pt, uiLayout *layout);
|
2017-11-02 18:19:11 +11:00
|
|
|
|
|
|
|
|
/* Only for convenience. */
|
|
|
|
|
void uiLayoutSetContextFromBut(uiLayout *layout, uiBut *but);
|
2009-05-28 23:13:42 +00:00
|
|
|
|
2021-11-05 14:56:22 +01:00
|
|
|
void uiLayoutSetOperatorContext(uiLayout *layout, wmOperatorCallContext opcontext);
|
2013-04-04 02:05:11 +00:00
|
|
|
void uiLayoutSetActive(uiLayout *layout, bool active);
|
2019-03-27 21:39:44 +11:00
|
|
|
void uiLayoutSetActiveDefault(uiLayout *layout, bool active_default);
|
2020-09-04 20:59:13 +02:00
|
|
|
void uiLayoutSetActivateInit(uiLayout *layout, bool activate_init);
|
2013-04-04 02:05:11 +00:00
|
|
|
void uiLayoutSetEnabled(uiLayout *layout, bool enabled);
|
|
|
|
|
void uiLayoutSetRedAlert(uiLayout *layout, bool redalert);
|
|
|
|
|
void uiLayoutSetAlignment(uiLayout *layout, char alignment);
|
2019-09-19 16:14:47 +02:00
|
|
|
void uiLayoutSetFixedSize(uiLayout *layout, bool fixed_size);
|
2013-04-04 02:05:11 +00:00
|
|
|
void uiLayoutSetKeepAspect(uiLayout *layout, bool keepaspect);
|
2009-06-03 00:04:48 +00:00
|
|
|
void uiLayoutSetScaleX(uiLayout *layout, float scale);
|
|
|
|
|
void uiLayoutSetScaleY(uiLayout *layout, float scale);
|
2018-09-26 17:44:35 +02:00
|
|
|
void uiLayoutSetUnitsX(uiLayout *layout, float unit);
|
|
|
|
|
void uiLayoutSetUnitsY(uiLayout *layout, float unit);
|
2020-12-19 10:07:13 -06:00
|
|
|
void uiLayoutSetEmboss(uiLayout *layout, eUIEmbossType emboss);
|
2018-05-28 16:40:27 +02:00
|
|
|
void uiLayoutSetPropSep(uiLayout *layout, bool is_sep);
|
2018-06-16 14:48:21 +02:00
|
|
|
void uiLayoutSetPropDecorate(uiLayout *layout, bool is_sep);
|
2018-12-20 11:59:31 +11:00
|
|
|
int uiLayoutGetLocalDir(const uiLayout *layout);
|
2024-04-16 12:18:45 +02:00
|
|
|
void uiLayoutSetSearchWeight(uiLayout *layout, float weight);
|
2009-05-28 23:37:55 +00:00
|
|
|
|
2023-06-18 01:39:21 +02:00
|
|
|
wmOperatorCallContext uiLayoutGetOperatorContext(uiLayout *layout);
|
2013-04-04 02:05:11 +00:00
|
|
|
bool uiLayoutGetActive(uiLayout *layout);
|
2019-03-27 21:39:44 +11:00
|
|
|
bool uiLayoutGetActiveDefault(uiLayout *layout);
|
2019-03-20 22:40:38 +11:00
|
|
|
bool uiLayoutGetActivateInit(uiLayout *layout);
|
2013-04-04 02:05:11 +00:00
|
|
|
bool uiLayoutGetEnabled(uiLayout *layout);
|
|
|
|
|
bool uiLayoutGetRedAlert(uiLayout *layout);
|
2009-05-28 23:37:55 +00:00
|
|
|
int uiLayoutGetAlignment(uiLayout *layout);
|
2019-09-19 16:14:47 +02:00
|
|
|
bool uiLayoutGetFixedSize(uiLayout *layout);
|
2013-04-04 02:05:11 +00:00
|
|
|
bool uiLayoutGetKeepAspect(uiLayout *layout);
|
2009-08-16 13:01:40 +00:00
|
|
|
int uiLayoutGetWidth(uiLayout *layout);
|
2009-06-03 00:04:48 +00:00
|
|
|
float uiLayoutGetScaleX(uiLayout *layout);
|
|
|
|
|
float uiLayoutGetScaleY(uiLayout *layout);
|
2018-09-26 17:44:35 +02:00
|
|
|
float uiLayoutGetUnitsX(uiLayout *layout);
|
|
|
|
|
float uiLayoutGetUnitsY(uiLayout *layout);
|
2020-12-19 10:07:13 -06:00
|
|
|
eUIEmbossType uiLayoutGetEmboss(uiLayout *layout);
|
2018-05-28 16:40:27 +02:00
|
|
|
bool uiLayoutGetPropSep(uiLayout *layout);
|
2018-06-16 14:48:21 +02:00
|
|
|
bool uiLayoutGetPropDecorate(uiLayout *layout);
|
Python: add Python API for layout panels
This adds a Python API for layout panels that have been introduced in #113584.
Two new methods on `UILayout` are added:
* `.panel(idname, text="...", default_closed=False) -> Optional[UILayout]`
* `.panel_prop(owner, prop_name, text="...") -> Optional[UILayout]`
Both create a panel and return `None` if the panel is collapsed. The difference lies
in how the open-close-state is stored. The first method internally manages the
open-close-state based on the provided identifier. The second one allows for
providing a boolean property that stores whether the panel is open. This is useful
when creating a dynamic of panels and when it is difficult to create a unique idname.
For the `.panel(...)` method, a new internal map on `Panel` is created which keeps
track of all the panel states based on the idname. Currently, there is no mechanism
for freeing any elements once they have been added to the map. This is unlikely to
cause a problem anytime soon, but we might need some kind of garbage collection
in the future.
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Before")
if panel := layout.panel("my_panel_id", text="Hello World", default_closed=False):
panel.label(text="Success")
if panel := layout.panel_prop(scene, "show_demo_panel", text="My Panel"):
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="After")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/116949
2024-01-11 19:08:45 +01:00
|
|
|
Panel *uiLayoutGetRootPanel(uiLayout *layout);
|
2024-04-16 12:18:45 +02:00
|
|
|
float uiLayoutGetSearchWeight(uiLayout *layout);
|
2009-05-28 23:37:55 +00:00
|
|
|
|
2024-07-29 23:52:38 +02:00
|
|
|
int uiLayoutListItemPaddingWidth();
|
|
|
|
|
void uiLayoutListItemAddPadding(uiLayout *layout);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/* Layout create functions. */
|
|
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
uiLayout *uiLayoutRow(uiLayout *layout, bool align);
|
UI: add support for uiLayout based panels
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
|
|
|
|
UI: Add ability to configure the header row of layout panels
There are many instances where customizing the header row is desired so
return both the header row layout and the main body layout.
For consistency and correctness, the arrow symbol and the is_open check
are always performed so callers only need to perform layout tasks.
The C++ side now receives a `PanelLayout` structure containing both:
```cpp
PanelLayout panel_layout = uiLayoutPanelWithHeader( ... );
uiItemL(panel_layout.header, ... );
if (panel_layout.body) {
...
}
```
And the Python side receives a tuple:
```python
header, body = layout.panel( ... )
header.label(...)
if body:
...
```
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Basic Panels")
header, panel = layout.panel("my_panel_id", default_closed=True)
header.label(text="Hello World")
if panel:
panel.label(text="Success")
header, panel = layout.panel_prop(scene, "show_demo_panel")
header.label(text="My Panel")
if panel:
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="Customized headers")
# Add a checkbox to the Panel header. text must be None for this panel
header, panel = layout.panel("my_panel_id-2", default_closed=True)
header.prop(scene, "use_checkmark", text="") # text must be empty for the checkbox
header.label(text="Checkmark at beginning")
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-3", default_closed=True)
header.label(text="Buttons at the end")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-4", default_closed=True)
header.prop(scene, "use_checkmark2", text="")
header.label(text="Both")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
bpy.types.Scene.use_checkmark = BoolProperty(default=False)
bpy.types.Scene.use_checkmark2 = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117248
2024-01-26 10:11:22 +01:00
|
|
|
struct PanelLayout {
|
|
|
|
|
uiLayout *header;
|
|
|
|
|
uiLayout *body;
|
|
|
|
|
};
|
|
|
|
|
|
UI: add support for uiLayout based panels
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
|
|
|
/**
|
|
|
|
|
* Create a "layout panel" which is a panel that is defined as part of the `uiLayout`. This allows
|
|
|
|
|
* creating expandable sections which can also be nested.
|
|
|
|
|
*
|
|
|
|
|
* The open-state of the panel is defined by an RNA property which is passed in as a pointer +
|
|
|
|
|
* property name pair. This gives the caller flexibility to decide who should own the open-state.
|
|
|
|
|
*
|
|
|
|
|
* \param C: The context is necessary because sometimes the panel may be forced to be open by the
|
2024-01-08 11:24:37 +11:00
|
|
|
* context even of the open-property is `false`. This can happen with e.g. property search.
|
|
|
|
|
* \param layout: The `uiLayout` that should contain the sub-panel.
|
|
|
|
|
* Only layouts that span the full width of the region are supported for now.
|
UI: add support for uiLayout based panels
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
|
|
|
* \param open_prop_owner: Data that contains the open-property.
|
|
|
|
|
* \param open_prop_name: Name of the open-property in `open_prop_owner`.
|
|
|
|
|
*
|
UI: Add ability to configure the header row of layout panels
There are many instances where customizing the header row is desired so
return both the header row layout and the main body layout.
For consistency and correctness, the arrow symbol and the is_open check
are always performed so callers only need to perform layout tasks.
The C++ side now receives a `PanelLayout` structure containing both:
```cpp
PanelLayout panel_layout = uiLayoutPanelWithHeader( ... );
uiItemL(panel_layout.header, ... );
if (panel_layout.body) {
...
}
```
And the Python side receives a tuple:
```python
header, body = layout.panel( ... )
header.label(...)
if body:
...
```
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Basic Panels")
header, panel = layout.panel("my_panel_id", default_closed=True)
header.label(text="Hello World")
if panel:
panel.label(text="Success")
header, panel = layout.panel_prop(scene, "show_demo_panel")
header.label(text="My Panel")
if panel:
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="Customized headers")
# Add a checkbox to the Panel header. text must be None for this panel
header, panel = layout.panel("my_panel_id-2", default_closed=True)
header.prop(scene, "use_checkmark", text="") # text must be empty for the checkbox
header.label(text="Checkmark at beginning")
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-3", default_closed=True)
header.label(text="Buttons at the end")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-4", default_closed=True)
header.prop(scene, "use_checkmark2", text="")
header.label(text="Both")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
bpy.types.Scene.use_checkmark = BoolProperty(default=False)
bpy.types.Scene.use_checkmark2 = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117248
2024-01-26 10:11:22 +01:00
|
|
|
* \return A #PanelLayout containing layouts for both the header row and the panel body. If the
|
|
|
|
|
* panel is closed and should not be drawn, the body layout will be NULL.
|
|
|
|
|
*/
|
2024-01-30 17:44:56 +01:00
|
|
|
PanelLayout uiLayoutPanelProp(const bContext *C,
|
|
|
|
|
uiLayout *layout,
|
|
|
|
|
PointerRNA *open_prop_owner,
|
|
|
|
|
const char *open_prop_name);
|
UI: Add ability to configure the header row of layout panels
There are many instances where customizing the header row is desired so
return both the header row layout and the main body layout.
For consistency and correctness, the arrow symbol and the is_open check
are always performed so callers only need to perform layout tasks.
The C++ side now receives a `PanelLayout` structure containing both:
```cpp
PanelLayout panel_layout = uiLayoutPanelWithHeader( ... );
uiItemL(panel_layout.header, ... );
if (panel_layout.body) {
...
}
```
And the Python side receives a tuple:
```python
header, body = layout.panel( ... )
header.label(...)
if body:
...
```
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Basic Panels")
header, panel = layout.panel("my_panel_id", default_closed=True)
header.label(text="Hello World")
if panel:
panel.label(text="Success")
header, panel = layout.panel_prop(scene, "show_demo_panel")
header.label(text="My Panel")
if panel:
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="Customized headers")
# Add a checkbox to the Panel header. text must be None for this panel
header, panel = layout.panel("my_panel_id-2", default_closed=True)
header.prop(scene, "use_checkmark", text="") # text must be empty for the checkbox
header.label(text="Checkmark at beginning")
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-3", default_closed=True)
header.label(text="Buttons at the end")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-4", default_closed=True)
header.prop(scene, "use_checkmark2", text="")
header.label(text="Both")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
bpy.types.Scene.use_checkmark = BoolProperty(default=False)
bpy.types.Scene.use_checkmark2 = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117248
2024-01-26 10:11:22 +01:00
|
|
|
|
|
|
|
|
/**
|
2024-01-30 17:44:56 +01:00
|
|
|
* Variant of #uiLayoutPanelProp that automatically creates the header row with the
|
|
|
|
|
* given label and only returns the body layout.
|
UI: Add ability to configure the header row of layout panels
There are many instances where customizing the header row is desired so
return both the header row layout and the main body layout.
For consistency and correctness, the arrow symbol and the is_open check
are always performed so callers only need to perform layout tasks.
The C++ side now receives a `PanelLayout` structure containing both:
```cpp
PanelLayout panel_layout = uiLayoutPanelWithHeader( ... );
uiItemL(panel_layout.header, ... );
if (panel_layout.body) {
...
}
```
And the Python side receives a tuple:
```python
header, body = layout.panel( ... )
header.label(...)
if body:
...
```
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Basic Panels")
header, panel = layout.panel("my_panel_id", default_closed=True)
header.label(text="Hello World")
if panel:
panel.label(text="Success")
header, panel = layout.panel_prop(scene, "show_demo_panel")
header.label(text="My Panel")
if panel:
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="Customized headers")
# Add a checkbox to the Panel header. text must be None for this panel
header, panel = layout.panel("my_panel_id-2", default_closed=True)
header.prop(scene, "use_checkmark", text="") # text must be empty for the checkbox
header.label(text="Checkmark at beginning")
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-3", default_closed=True)
header.label(text="Buttons at the end")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-4", default_closed=True)
header.prop(scene, "use_checkmark2", text="")
header.label(text="Both")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
bpy.types.Scene.use_checkmark = BoolProperty(default=False)
bpy.types.Scene.use_checkmark2 = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117248
2024-01-26 10:11:22 +01:00
|
|
|
*
|
2024-01-30 17:44:56 +01:00
|
|
|
* \param label: Text that's shown in the panel header. It should already be translated.
|
|
|
|
|
*
|
|
|
|
|
* \return NULL if the panel is closed and should not be drawn, otherwise the layout where the
|
|
|
|
|
* sub-panel should be inserted into.
|
|
|
|
|
*/
|
|
|
|
|
uiLayout *uiLayoutPanelProp(const bContext *C,
|
|
|
|
|
uiLayout *layout,
|
|
|
|
|
PointerRNA *open_prop_owner,
|
|
|
|
|
const char *open_prop_name,
|
|
|
|
|
const char *label);
|
|
|
|
|
|
2025-01-10 14:51:19 +01:00
|
|
|
uiLayout *uiLayoutPanelPropWithBoolHeader(const bContext *C,
|
|
|
|
|
uiLayout *layout,
|
|
|
|
|
PointerRNA *open_prop_owner,
|
|
|
|
|
const blender::StringRefNull open_prop_name,
|
|
|
|
|
const blender::StringRefNull bool_prop_name,
|
|
|
|
|
const std::optional<blender::StringRefNull> label);
|
|
|
|
|
|
2024-01-30 17:44:56 +01:00
|
|
|
/**
|
|
|
|
|
* Variant of #uiLayoutPanelProp that automatically stores the open-close-state in the root
|
|
|
|
|
* panel. When a dynamic number of panels is required, it's recommended to use #uiLayoutPanelProp
|
2024-02-06 22:25:37 +11:00
|
|
|
* instead of passing in generated id names.
|
2024-01-30 17:44:56 +01:00
|
|
|
*
|
|
|
|
|
* \param idname: String that identifies the open-close-state in the root panel.
|
|
|
|
|
*/
|
|
|
|
|
PanelLayout uiLayoutPanel(const bContext *C,
|
|
|
|
|
uiLayout *layout,
|
|
|
|
|
const char *idname,
|
|
|
|
|
bool default_closed);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Variant of #uiLayoutPanel that automatically creates the header row with the given label and
|
|
|
|
|
* only returns the body layout.
|
|
|
|
|
*
|
|
|
|
|
* \param label: Text that's shown in the panel header. It should already be translated.
|
UI: Add ability to configure the header row of layout panels
There are many instances where customizing the header row is desired so
return both the header row layout and the main body layout.
For consistency and correctness, the arrow symbol and the is_open check
are always performed so callers only need to perform layout tasks.
The C++ side now receives a `PanelLayout` structure containing both:
```cpp
PanelLayout panel_layout = uiLayoutPanelWithHeader( ... );
uiItemL(panel_layout.header, ... );
if (panel_layout.body) {
...
}
```
And the Python side receives a tuple:
```python
header, body = layout.panel( ... )
header.label(...)
if body:
...
```
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Basic Panels")
header, panel = layout.panel("my_panel_id", default_closed=True)
header.label(text="Hello World")
if panel:
panel.label(text="Success")
header, panel = layout.panel_prop(scene, "show_demo_panel")
header.label(text="My Panel")
if panel:
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="Customized headers")
# Add a checkbox to the Panel header. text must be None for this panel
header, panel = layout.panel("my_panel_id-2", default_closed=True)
header.prop(scene, "use_checkmark", text="") # text must be empty for the checkbox
header.label(text="Checkmark at beginning")
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-3", default_closed=True)
header.label(text="Buttons at the end")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
header, panel = layout.panel("my_panel_id-4", default_closed=True)
header.prop(scene, "use_checkmark2", text="")
header.label(text="Both")
header.operator("mesh.primitive_cube_add", text="", icon='EXPORT')
header.operator("mesh.primitive_cube_add", text="", icon='X')
if panel:
panel.label(text="Success")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
bpy.types.Scene.use_checkmark = BoolProperty(default=False)
bpy.types.Scene.use_checkmark2 = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/117248
2024-01-26 10:11:22 +01:00
|
|
|
*
|
UI: add support for uiLayout based panels
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
|
|
|
* \return NULL if the panel is closed and should not be drawn, otherwise the layout where the
|
|
|
|
|
* sub-panel should be inserted into.
|
|
|
|
|
*/
|
|
|
|
|
uiLayout *uiLayoutPanel(const bContext *C,
|
|
|
|
|
uiLayout *layout,
|
2024-01-30 17:44:56 +01:00
|
|
|
const char *idname,
|
|
|
|
|
bool default_closed,
|
|
|
|
|
const char *label);
|
UI: add support for uiLayout based panels
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
|
|
|
|
|
|
|
|
bool uiLayoutEndsWithPanelHeader(const uiLayout &layout);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* See #uiLayoutColumnWithHeading().
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
uiLayout *uiLayoutRowWithHeading(uiLayout *layout, bool align, blender::StringRef heading);
|
2018-07-01 15:47:09 +02:00
|
|
|
uiLayout *uiLayoutColumn(uiLayout *layout, bool align);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Variant of #uiLayoutColumn() that sets a heading label for the layout if the first item is
|
|
|
|
|
* added through #uiItemFullR(). If split layout is used and the item has no string to add to the
|
|
|
|
|
* first split-column, the heading is added there instead. Otherwise the heading inserted with a
|
|
|
|
|
* new row.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
uiLayout *uiLayoutColumnWithHeading(uiLayout *layout, bool align, blender::StringRef heading);
|
2018-07-01 15:47:09 +02:00
|
|
|
uiLayout *uiLayoutColumnFlow(uiLayout *layout, int number, bool align);
|
2018-06-09 16:50:05 +02:00
|
|
|
uiLayout *uiLayoutGridFlow(uiLayout *layout,
|
2018-07-01 16:22:06 +02:00
|
|
|
bool row_major,
|
|
|
|
|
int columns_len,
|
|
|
|
|
bool even_columns,
|
|
|
|
|
bool even_rows,
|
|
|
|
|
bool align);
|
2009-04-16 12:17:58 +00:00
|
|
|
uiLayout *uiLayoutBox(uiLayout *layout);
|
2018-07-09 06:38:07 +02:00
|
|
|
uiLayout *uiLayoutListBox(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
uiList *ui_list,
|
|
|
|
|
PointerRNA *actptr,
|
|
|
|
|
PropertyRNA *actprop);
|
2018-07-01 15:47:09 +02:00
|
|
|
uiLayout *uiLayoutAbsolute(uiLayout *layout, bool align);
|
|
|
|
|
uiLayout *uiLayoutSplit(uiLayout *layout, float percentage, bool align);
|
2009-10-21 20:58:10 +00:00
|
|
|
uiLayout *uiLayoutOverlap(uiLayout *layout);
|
2009-10-09 10:45:11 +00:00
|
|
|
uiBlock *uiLayoutAbsoluteBlock(uiLayout *layout);
|
2024-06-06 14:55:23 +02:00
|
|
|
/** Pie menu layout: Buttons are arranged around a center. */
|
Pie Menus C code backend.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
2014-08-11 10:39:59 +02:00
|
|
|
uiLayout *uiLayoutRadial(uiLayout *layout);
|
2009-05-19 17:13:33 +00:00
|
|
|
|
2009-04-16 12:17:58 +00:00
|
|
|
/* templates */
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateHeader(uiLayout *layout, bContext *C);
|
2018-01-03 21:54:02 +11:00
|
|
|
void uiTemplateID(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-07-31 10:22:19 +02:00
|
|
|
const char *newop,
|
|
|
|
|
const char *openop,
|
|
|
|
|
const char *unlinkop,
|
2024-09-17 12:22:18 +02:00
|
|
|
int filter = UI_TEMPLATE_ID_FILTER_ALL,
|
|
|
|
|
bool live_icon = false,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> text = std::nullopt);
|
2018-01-03 21:54:02 +11:00
|
|
|
void uiTemplateIDBrowse(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-01-03 21:54:02 +11:00
|
|
|
const char *newop,
|
|
|
|
|
const char *openop,
|
|
|
|
|
const char *unlinkop,
|
2024-09-17 12:22:18 +02:00
|
|
|
int filter = UI_TEMPLATE_ID_FILTER_ALL,
|
|
|
|
|
const char *text = nullptr);
|
2018-01-03 21:54:02 +11:00
|
|
|
void uiTemplateIDPreview(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-11-02 17:30:09 +01:00
|
|
|
const char *newop,
|
|
|
|
|
const char *openop,
|
|
|
|
|
const char *unlinkop,
|
|
|
|
|
int rows,
|
|
|
|
|
int cols,
|
2024-09-17 12:22:18 +02:00
|
|
|
int filter = UI_TEMPLATE_ID_FILTER_ALL,
|
|
|
|
|
bool hide_buttons = false);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Version of #uiTemplateID using tabs.
|
|
|
|
|
*/
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
void uiTemplateIDTabs(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-08-28 15:12:14 +02:00
|
|
|
const char *newop,
|
|
|
|
|
const char *menu,
|
2024-09-17 12:22:18 +02:00
|
|
|
int filter = UI_TEMPLATE_ID_FILTER_ALL);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This is for selecting the type of ID-block to use,
|
|
|
|
|
* and then from the relevant type choosing the block to use.
|
|
|
|
|
*
|
|
|
|
|
* \param propname: property identifier for property that ID-pointer gets stored to.
|
|
|
|
|
* \param proptypename: property identifier for property
|
|
|
|
|
* used to determine the type of ID-pointer that can be used.
|
|
|
|
|
*/
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplateAnyID(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
blender::StringRefNull proptypename,
|
|
|
|
|
std::optional<blender::StringRef> text);
|
2024-08-23 11:07:16 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Action selector.
|
|
|
|
|
*
|
2024-08-26 11:50:15 +10:00
|
|
|
* This is a specialization of #uiTemplateID, hard-coded to assign Actions to the given ID.
|
|
|
|
|
* Such a specialization is necessary, as the RNA property (`id.animation_data.action`) does not
|
2024-08-23 11:07:16 +02:00
|
|
|
* exist when the ID's `adt` pointer is `nullptr`. In that case uiTemplateID will not be able
|
|
|
|
|
* to find the RNA type of that property, which in turn it needs to determine the type of IDs to
|
|
|
|
|
* show.
|
|
|
|
|
*/
|
|
|
|
|
void uiTemplateAction(uiLayout *layout,
|
|
|
|
|
const bContext *C,
|
|
|
|
|
ID *id,
|
|
|
|
|
const char *newop,
|
|
|
|
|
const char *unlinkop,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> text);
|
2024-08-23 11:07:16 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Search menu to pick an item from a collection.
|
|
|
|
|
* A version of uiTemplateID that works for non-ID types.
|
|
|
|
|
*/
|
2017-05-12 01:42:42 +02:00
|
|
|
void uiTemplateSearch(uiLayout *layout,
|
2024-09-10 11:08:10 +02:00
|
|
|
const bContext *C,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *searchptr,
|
2017-05-12 01:42:42 +02:00
|
|
|
const char *searchpropname,
|
|
|
|
|
const char *newop,
|
2024-09-20 12:24:36 +02:00
|
|
|
const char *unlinkop,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> text = std::nullopt);
|
2017-05-12 01:42:42 +02:00
|
|
|
void uiTemplateSearchPreview(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *searchptr,
|
2017-05-12 01:42:42 +02:00
|
|
|
const char *searchpropname,
|
|
|
|
|
const char *newop,
|
|
|
|
|
const char *unlinkop,
|
2022-01-07 11:38:08 +11:00
|
|
|
int rows,
|
2024-09-20 12:24:36 +02:00
|
|
|
int cols,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> text = std::nullopt);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This is creating/editing RNA-Paths
|
|
|
|
|
*
|
|
|
|
|
* - ptr: struct which holds the path property
|
|
|
|
|
* - propname: property identifier for property that path gets stored to
|
|
|
|
|
* - root_ptr: struct that path gets built from
|
|
|
|
|
*/
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplatePathBuilder(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *root_ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> text);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateModifiers(uiLayout *layout, bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the shader effect panels don't match the data and rebuild the panels if so.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateShaderFx(uiLayout *layout, bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the constraint panels don't match the data and rebuild the panels if so.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateConstraints(uiLayout *layout, bContext *C, bool use_bone_constraints);
|
2020-06-19 12:40:48 -04:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiLayout *uiTemplateGpencilModifier(uiLayout *layout, bContext *C, PointerRNA *ptr);
|
2018-07-31 10:22:19 +02:00
|
|
|
void uiTemplateGpencilColorPreview(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-11-03 15:55:33 +11:00
|
|
|
int rows,
|
|
|
|
|
int cols,
|
|
|
|
|
float scale,
|
|
|
|
|
int filter);
|
2018-07-31 10:22:19 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateOperatorRedoProperties(uiLayout *layout, const bContext *C);
|
2018-04-25 07:52:40 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateConstraintHeader(uiLayout *layout, PointerRNA *ptr);
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplatePreview(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
ID *id,
|
2018-07-09 06:38:07 +02:00
|
|
|
bool show_buttons,
|
2023-08-04 22:15:25 -04:00
|
|
|
ID *parent,
|
|
|
|
|
MTex *slot,
|
2018-07-09 06:38:07 +02:00
|
|
|
const char *preview_id);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiTemplateColorRamp(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
bool expand);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \param icon_scale: Scale of the icon, 1x == button height.
|
|
|
|
|
*/
|
2018-06-14 10:38:17 +02:00
|
|
|
void uiTemplateIcon(uiLayout *layout, int icon_value, float icon_scale);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \param icon_scale: Scale of the icon, 1x == button height.
|
|
|
|
|
*/
|
2019-01-02 18:18:54 +11:00
|
|
|
void uiTemplateIconView(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2019-01-02 18:18:54 +11:00
|
|
|
bool show_labels,
|
|
|
|
|
float icon_scale,
|
|
|
|
|
float icon_scale_popup);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiTemplateHistogram(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
|
|
|
|
void uiTemplateWaveform(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
|
|
|
|
void uiTemplateVectorscope(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplateCurveMapping(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-07-09 06:38:07 +02:00
|
|
|
int type,
|
2018-08-23 10:25:54 +02:00
|
|
|
bool levels,
|
|
|
|
|
bool brush,
|
|
|
|
|
bool neg_slope,
|
|
|
|
|
bool tone);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Template for a path creation widget intended for custom bevel profiles.
|
|
|
|
|
* This section is quite similar to #uiTemplateCurveMapping, but with reduced complexity.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiTemplateCurveProfile(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* This template now follows User Preference for type - name is not correct anymore.
|
|
|
|
|
*/
|
2018-07-01 15:47:09 +02:00
|
|
|
void uiTemplateColorPicker(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2018-07-01 15:47:09 +02:00
|
|
|
bool value_slider,
|
|
|
|
|
bool lock,
|
|
|
|
|
bool lock_luminosity,
|
|
|
|
|
bool cubic);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiTemplatePalette(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
bool colors);
|
|
|
|
|
void uiTemplateCryptoPicker(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
int icon);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2025-01-04 16:26:39 +11:00
|
|
|
* TODO: for now, grouping of layers is determined by dividing up the length of
|
|
|
|
|
* the array of layer bit-flags.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplateLayers(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *used_ptr,
|
2018-07-09 06:38:07 +02:00
|
|
|
const char *used_propname,
|
|
|
|
|
int active_layer);
|
2018-07-01 15:47:09 +02:00
|
|
|
void uiTemplateImage(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *userptr,
|
2018-07-01 15:47:09 +02:00
|
|
|
bool compact,
|
|
|
|
|
bool multiview);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateImageSettings(uiLayout *layout, PointerRNA *imfptr, bool color_management);
|
|
|
|
|
void uiTemplateImageStereo3d(uiLayout *layout, PointerRNA *stereo3d_format_ptr);
|
|
|
|
|
void uiTemplateImageViews(uiLayout *layout, PointerRNA *imaptr);
|
|
|
|
|
void uiTemplateImageFormatViews(uiLayout *layout, PointerRNA *imfptr, PointerRNA *ptr);
|
|
|
|
|
void uiTemplateImageLayers(uiLayout *layout, bContext *C, Image *ima, ImageUser *iuser);
|
|
|
|
|
void uiTemplateImageInfo(uiLayout *layout, bContext *C, Image *ima, ImageUser *iuser);
|
|
|
|
|
void uiTemplateRunningJobs(uiLayout *layout, bContext *C);
|
2014-11-09 21:20:40 +01:00
|
|
|
void UI_but_func_operator_search(uiBut *but);
|
2009-06-30 19:20:45 +00:00
|
|
|
void uiTemplateOperatorSearch(uiLayout *layout);
|
2020-03-24 11:34:18 +11:00
|
|
|
|
2023-09-06 18:16:45 +02:00
|
|
|
void UI_but_func_menu_search(uiBut *but, const char *single_menu_idname = nullptr);
|
2020-03-24 11:34:18 +11:00
|
|
|
void uiTemplateMenuSearch(uiLayout *layout);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draw Operator property buttons for redoing execution with different settings.
|
|
|
|
|
* This function does not initialize the layout,
|
|
|
|
|
* functions can be called on the layout before and after.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateOperatorPropertyButs(
|
|
|
|
|
const bContext *C, uiLayout *layout, wmOperator *op, eButLabelAlign label_align, short flag);
|
|
|
|
|
void uiTemplateHeader3D_mode(uiLayout *layout, bContext *C);
|
|
|
|
|
void uiTemplateEditModeSelection(uiLayout *layout, bContext *C);
|
|
|
|
|
void uiTemplateReportsBanner(uiLayout *layout, bContext *C);
|
|
|
|
|
void uiTemplateInputStatus(uiLayout *layout, bContext *C);
|
|
|
|
|
void uiTemplateStatusInfo(uiLayout *layout, bContext *C);
|
|
|
|
|
void uiTemplateKeymapItemProperties(uiLayout *layout, PointerRNA *ptr);
|
|
|
|
|
|
|
|
|
|
bool uiTemplateEventFromKeymapItem(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
const blender::StringRefNull text,
|
2023-08-04 22:15:25 -04:00
|
|
|
const wmKeyMapItem *kmi,
|
2019-10-28 02:51:26 +11:00
|
|
|
bool text_fallback);
|
|
|
|
|
|
2024-04-22 20:03:11 +02:00
|
|
|
/* Draw keymap item for status bar. Returns number of items consumed,
|
|
|
|
|
* as X/Y/Z items may get merged to use less space. */
|
|
|
|
|
int uiTemplateStatusBarModalItem(uiLayout *layout,
|
|
|
|
|
const wmKeyMap *keymap,
|
|
|
|
|
const EnumPropertyItem *item);
|
|
|
|
|
|
2013-03-18 16:34:57 +00:00
|
|
|
void uiTemplateComponentMenu(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
blender::StringRef name);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateNodeSocket(uiLayout *layout, bContext *C, const float color[4]);
|
2021-12-23 18:05:00 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Draw the main CacheFile properties and operators (file path, scale, etc.), that is those which
|
|
|
|
|
* do not have their own dedicated template functions.
|
|
|
|
|
*/
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
void uiTemplateCacheFile(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname);
|
2009-03-13 13:38:41 +00:00
|
|
|
|
2021-12-23 18:05:00 +01:00
|
|
|
/**
|
|
|
|
|
* Lookup the CacheFile PointerRNA of the given pointer and return it in the output parameter.
|
|
|
|
|
* Returns true if `ptr` has a RNACacheFile, false otherwise. If false, the output parameter is not
|
|
|
|
|
* initialized.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
bool uiTemplateCacheFilePointer(PointerRNA *ptr,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
PointerRNA *r_file_ptr);
|
2021-12-23 18:05:00 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Draw the velocity related properties of the CacheFile.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateCacheFileVelocity(uiLayout *layout, PointerRNA *fileptr);
|
2021-12-23 18:05:00 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Draw the render procedural related properties of the CacheFile.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateCacheFileProcedural(uiLayout *layout, const bContext *C, PointerRNA *fileptr);
|
2021-12-23 18:05:00 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Draw the time related properties of the CacheFile.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateCacheFileTimeSettings(uiLayout *layout, PointerRNA *fileptr);
|
2021-12-23 18:05:00 +01:00
|
|
|
|
Alembic: add support for reading override layers
Override layers are a standard feature of Alembic, where archives can override
data from other archives, provided that the hierarchies match.
This is useful for modifying a UV map, updating an animation, or even creating
some sort of LOD system where low resolution meshes are swapped by high resolution
versions.
It is possible to add UV maps and vertex colors using this system, however, they
will only appear in the spreadsheet editor when viewing evaluated data, as the UV
map and Vertex color UI only show data present on the original mesh.
Implementation wise, this adds a `CacheFileLayer` data structure to the `CacheFile`
DNA, as well as some operators and UI to present and manage the layers. For both
the Alembic importer and the Cycles procedural, the main change is creating an
archive from a list of filepaths, instead of a single one.
After importing the base file through the regular import operator, layers can be added
to or removed from the `CacheFile` via the UI list under the `Override Layers` panel
located in the Mesh Sequence Cache modifier. Layers can also be moved around or
hidden.
See differential page for tests files and demos.
Reviewed by: brecht, sybren
Differential Revision: https://developer.blender.org/D13603
2022-01-17 14:50:47 +01:00
|
|
|
/**
|
|
|
|
|
* Draw the override layers related properties of the CacheFile.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateCacheFileLayers(uiLayout *layout, const bContext *C, PointerRNA *fileptr);
|
Alembic: add support for reading override layers
Override layers are a standard feature of Alembic, where archives can override
data from other archives, provided that the hierarchies match.
This is useful for modifying a UV map, updating an animation, or even creating
some sort of LOD system where low resolution meshes are swapped by high resolution
versions.
It is possible to add UV maps and vertex colors using this system, however, they
will only appear in the spreadsheet editor when viewing evaluated data, as the UV
map and Vertex color UI only show data present on the original mesh.
Implementation wise, this adds a `CacheFileLayer` data structure to the `CacheFile`
DNA, as well as some operators and UI to present and manage the layers. For both
the Alembic importer and the Cycles procedural, the main change is creating an
archive from a list of filepaths, instead of a single one.
After importing the base file through the regular import operator, layers can be added
to or removed from the `CacheFile` via the UI list under the `Override Layers` panel
located in the Mesh Sequence Cache modifier. Layers can also be moved around or
hidden.
See differential page for tests files and demos.
Reviewed by: brecht, sybren
Differential Revision: https://developer.blender.org/D13603
2022-01-17 14:50:47 +01:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Default UIList class name, keep in sync with its declaration in `bl_ui/__init__.py`. */
|
2013-02-18 14:03:26 +00:00
|
|
|
#define UI_UL_DEFAULT_CLASS_NAME "UI_UL_list"
|
2021-07-14 16:01:53 +02:00
|
|
|
enum uiTemplateListFlags {
|
|
|
|
|
UI_TEMPLATE_LIST_FLAG_NONE = 0,
|
|
|
|
|
UI_TEMPLATE_LIST_SORT_REVERSE = (1 << 0),
|
|
|
|
|
UI_TEMPLATE_LIST_SORT_LOCK = (1 << 1),
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Don't allow resizing the list, i.e. don't add the grip button. */
|
2021-07-14 16:01:53 +02:00
|
|
|
UI_TEMPLATE_LIST_NO_GRIP = (1 << 2),
|
2021-09-13 18:40:21 +02:00
|
|
|
/** Do not show filtering options, not even the button to expand/collapse them. Also hides the
|
|
|
|
|
* grip button. */
|
|
|
|
|
UI_TEMPLATE_LIST_NO_FILTER_OPTIONS = (1 << 3),
|
|
|
|
|
/** For #UILST_LAYOUT_BIG_PREVIEW_GRID, don't reserve space for the name label. */
|
|
|
|
|
UI_TEMPLATE_LIST_NO_NAMES = (1 << 4),
|
2021-07-14 16:01:53 +02:00
|
|
|
|
|
|
|
|
UI_TEMPLATE_LIST_FLAGS_LAST
|
|
|
|
|
};
|
2023-06-18 01:39:21 +02:00
|
|
|
ENUM_OPERATORS(uiTemplateListFlags, UI_TEMPLATE_LIST_FLAGS_LAST);
|
2021-07-14 16:01:53 +02:00
|
|
|
|
2018-07-09 06:38:07 +02:00
|
|
|
void uiTemplateList(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
2018-07-09 06:38:07 +02:00
|
|
|
const char *listtype_name,
|
|
|
|
|
const char *list_id,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *dataptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *active_dataptr,
|
2018-07-09 06:38:07 +02:00
|
|
|
const char *active_propname,
|
|
|
|
|
const char *item_dyntip_propname,
|
2019-01-09 15:48:09 +01:00
|
|
|
int rows,
|
|
|
|
|
int maxrows,
|
|
|
|
|
int layout_type,
|
|
|
|
|
int columns,
|
2021-07-14 16:01:53 +02:00
|
|
|
enum uiTemplateListFlags flags);
|
2023-08-04 22:15:25 -04:00
|
|
|
uiList *uiTemplateList_ex(uiLayout *layout,
|
|
|
|
|
const bContext *C,
|
|
|
|
|
const char *listtype_name,
|
|
|
|
|
const char *list_id,
|
|
|
|
|
PointerRNA *dataptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *active_dataptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull active_propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
const char *item_dyntip_propname,
|
|
|
|
|
int rows,
|
|
|
|
|
int maxrows,
|
|
|
|
|
int layout_type,
|
|
|
|
|
int columns,
|
|
|
|
|
enum uiTemplateListFlags flags,
|
|
|
|
|
void *customdata);
|
|
|
|
|
|
|
|
|
|
void uiTemplateNodeLink(
|
|
|
|
|
uiLayout *layout, bContext *C, bNodeTree *ntree, bNode *node, bNodeSocket *input);
|
|
|
|
|
void uiTemplateNodeView(
|
|
|
|
|
uiLayout *layout, bContext *C, bNodeTree *ntree, bNode *node, bNodeSocket *input);
|
|
|
|
|
void uiTemplateTextureUser(uiLayout *layout, bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Button to quickly show texture in Properties Editor texture tab.
|
|
|
|
|
*/
|
2011-11-08 13:07:16 +00:00
|
|
|
void uiTemplateTextureShow(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop);
|
|
|
|
|
|
|
|
|
|
void uiTemplateMovieClip(
|
2024-12-06 14:08:10 +01:00
|
|
|
uiLayout *layout, bContext *C, PointerRNA *ptr, blender::StringRefNull propname, bool compact);
|
|
|
|
|
void uiTemplateTrack(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateMarker(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *userptr,
|
|
|
|
|
PointerRNA *trackptr,
|
2018-07-01 15:47:09 +02:00
|
|
|
bool compact);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateMovieclipInformation(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *userptr);
|
|
|
|
|
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiTemplateColorspaceSettings(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
blender::StringRefNull propname);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateColormanagedViewSettings(uiLayout *layout,
|
|
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname);
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 10:05:07 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int uiTemplateRecentFiles(uiLayout *layout, int rows);
|
|
|
|
|
void uiTemplateFileSelectPath(uiLayout *layout, bContext *C, FileSelectParams *params);
|
2021-09-13 18:40:21 +02:00
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
UI_TEMPLATE_ASSET_DRAW_NO_NAMES = (1 << 0),
|
|
|
|
|
UI_TEMPLATE_ASSET_DRAW_NO_FILTER = (1 << 1),
|
|
|
|
|
UI_TEMPLATE_ASSET_DRAW_NO_LIBRARY = (1 << 2),
|
|
|
|
|
};
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateAssetView(uiLayout *layout,
|
|
|
|
|
const bContext *C,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *list_id,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *asset_library_dataptr,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *asset_library_propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *assets_dataptr,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *assets_propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *active_dataptr,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *active_propname,
|
2024-02-21 14:23:17 +01:00
|
|
|
const blender::ed::asset::AssetFilterSettings *filter_settings,
|
2022-01-07 11:38:08 +11:00
|
|
|
int display_flags,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *activate_opname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_activate_op_properties,
|
UI/Assets: Initial Asset View UI template
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
2021-07-13 18:07:57 +02:00
|
|
|
const char *drag_opname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_drag_op_properties);
|
2018-09-18 17:44:14 +02:00
|
|
|
|
2024-05-16 00:11:47 +02:00
|
|
|
namespace blender::ui {
|
|
|
|
|
|
2025-02-04 13:53:30 +01:00
|
|
|
void template_asset_shelf_popover(
|
|
|
|
|
uiLayout &layout, const bContext &C, StringRefNull asset_shelf_id, StringRef name, int icon);
|
2024-05-16 00:11:47 +02:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-22 17:44:25 +02:00
|
|
|
void uiTemplateLightLinkingCollection(uiLayout *layout,
|
UI: Support persistent view state, write tree-view height to files
Adds support for saving some view state persistently and uses this to keep the
height of a tree-view, even as the region containing it is hidden, or the file
re-loaded.
Fixes #129058.
Basically the design is to have state stored in the region, so it can be saved
to files. Views types (tree-view, grid-view, etc) can decide themselves if they
have state to be preserved, and what state that is. If a view wants to preserve
state, it's stored in a list inside the region, identified by the view's idname.
Limitation is that multiple instances of the same view would share these bits of
state, in practice I don't think that's ever an issue.
More state can be added to be preserved as needed. Since different kinds of
views may require different state, I was thinking we could add ID properties to
`uiViewState` even, making it much more dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/130292
2024-11-18 18:19:48 +01:00
|
|
|
bContext *C,
|
2023-09-22 17:44:25 +02:00
|
|
|
uiLayout *context_layout,
|
|
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname);
|
2023-05-24 13:36:13 +02:00
|
|
|
|
2023-12-28 16:10:02 +01:00
|
|
|
void uiTemplateBoneCollectionTree(uiLayout *layout, bContext *C);
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiTemplateGreasePencilLayerTree(uiLayout *layout, bContext *C);
|
2023-06-22 10:51:43 +02:00
|
|
|
|
UI: Support persistent view state, write tree-view height to files
Adds support for saving some view state persistently and uses this to keep the
height of a tree-view, even as the region containing it is hidden, or the file
re-loaded.
Fixes #129058.
Basically the design is to have state stored in the region, so it can be saved
to files. Views types (tree-view, grid-view, etc) can decide themselves if they
have state to be preserved, and what state that is. If a view wants to preserve
state, it's stored in a list inside the region, identified by the view's idname.
Limitation is that multiple instances of the same view would share these bits of
state, in practice I don't think that's ever an issue.
More state can be added to be preserved as needed. Since different kinds of
views may require different state, I was thinking we could add ID properties to
`uiViewState` even, making it much more dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/130292
2024-11-18 18:19:48 +01:00
|
|
|
void uiTemplateNodeTreeInterface(uiLayout *layout, bContext *C, PointerRNA *ptr);
|
2024-01-16 13:37:57 +01:00
|
|
|
/**
|
|
|
|
|
* Draw all node buttons and socket default values with the same panel structure used by the node.
|
|
|
|
|
*/
|
|
|
|
|
void uiTemplateNodeInputs(uiLayout *layout, bContext *C, PointerRNA *ptr);
|
2023-08-30 12:37:21 +02:00
|
|
|
|
2024-04-08 22:10:39 +02:00
|
|
|
void uiTemplateCollectionExporters(uiLayout *layout, bContext *C);
|
|
|
|
|
|
2024-03-22 16:04:03 +01:00
|
|
|
/**
|
|
|
|
|
* \return: True if the list item with unfiltered, unordered index \a item_idx is visible given the
|
|
|
|
|
* current filter settings.
|
|
|
|
|
*/
|
|
|
|
|
bool UI_list_item_index_is_filtered_visible(const struct uiList *ui_list, int item_idx);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-02-28 12:13:20 +11:00
|
|
|
* \return An RNA pointer for the operator properties.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *UI_list_custom_activate_operator_set(uiList *ui_list,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2023-08-04 22:15:25 -04:00
|
|
|
bool create_properties);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-02-28 12:13:20 +11:00
|
|
|
* \return An RNA pointer for the operator properties.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *UI_list_custom_drag_operator_set(uiList *ui_list,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2023-08-04 22:15:25 -04:00
|
|
|
bool create_properties);
|
2021-07-09 21:46:55 +02:00
|
|
|
|
2009-03-13 13:38:41 +00:00
|
|
|
/* items */
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemO(uiLayout *layout,
|
|
|
|
|
std::optional<blender::StringRef> name,
|
|
|
|
|
int icon,
|
|
|
|
|
blender::StringRefNull opname);
|
2012-01-22 03:30:07 +00:00
|
|
|
void uiItemEnumO_ptr(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2012-01-22 03:30:07 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2012-01-22 03:30:07 +00:00
|
|
|
int value);
|
2010-12-03 17:05:21 +00:00
|
|
|
void uiItemEnumO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
std::optional<blender::StringRef> name,
|
2010-12-03 17:05:21 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2010-12-03 17:05:21 +00:00
|
|
|
int value);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For use in cases where we have.
|
|
|
|
|
*/
|
2011-03-24 12:36:12 +00:00
|
|
|
void uiItemEnumO_value(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull name,
|
2011-03-24 12:36:12 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2011-03-24 12:36:12 +00:00
|
|
|
int value);
|
2010-12-03 17:05:21 +00:00
|
|
|
void uiItemEnumO_string(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRef name,
|
2010-12-03 17:05:21 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2024-07-27 13:20:43 +10:00
|
|
|
const char *value_str);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemsEnumO(uiLayout *layout,
|
|
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname);
|
2010-12-03 17:05:21 +00:00
|
|
|
void uiItemBooleanO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2010-12-03 17:05:21 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2010-11-17 09:45:45 +00:00
|
|
|
int value);
|
|
|
|
|
void uiItemIntO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2010-11-17 09:45:45 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2010-11-17 09:45:45 +00:00
|
|
|
int value);
|
|
|
|
|
void uiItemFloatO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2010-12-03 17:05:21 +00:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2010-12-03 17:05:21 +00:00
|
|
|
float value);
|
|
|
|
|
void uiItemStringO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2017-10-31 16:58:26 +11:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2010-12-03 17:05:21 +00:00
|
|
|
const char *value);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-31 16:58:26 +11:00
|
|
|
void uiItemFullO_ptr(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2017-10-31 16:58:26 +11:00
|
|
|
int icon,
|
2023-08-04 22:15:25 -04:00
|
|
|
IDProperty *properties,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_opptr);
|
2017-10-31 16:58:26 +11:00
|
|
|
void uiItemFullO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
std::optional<blender::StringRef> name,
|
2017-10-31 16:58:26 +11:00
|
|
|
int icon,
|
2023-08-04 22:15:25 -04:00
|
|
|
IDProperty *properties,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_opptr);
|
2017-11-02 04:30:07 +11:00
|
|
|
void uiItemFullOMenuHold_ptr(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRef> name,
|
2017-11-02 04:30:07 +11:00
|
|
|
int icon,
|
2023-08-04 22:15:25 -04:00
|
|
|
IDProperty *properties,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2017-11-02 04:30:07 +11:00
|
|
|
const char *menu_id, /* extra menu arg. */
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_opptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-11-17 09:45:45 +00:00
|
|
|
void uiItemR(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2010-11-17 09:45:45 +00:00
|
|
|
int icon);
|
2019-03-25 18:55:38 +11:00
|
|
|
void uiItemFullR(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2019-03-25 18:55:38 +11:00
|
|
|
int index,
|
|
|
|
|
int value,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name_opt,
|
2023-10-12 11:44:08 -07:00
|
|
|
int icon,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> placeholder = std::nullopt);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Use a wrapper function since re-implementing all the logic in this function would be messy.
|
|
|
|
|
*/
|
2019-03-25 18:55:38 +11:00
|
|
|
void uiItemFullR_with_popover(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2019-03-25 18:55:38 +11:00
|
|
|
int index,
|
|
|
|
|
int value,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2019-03-25 18:55:38 +11:00
|
|
|
int icon,
|
|
|
|
|
const char *panel_type);
|
2019-03-25 20:31:06 +11:00
|
|
|
void uiItemFullR_with_menu(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2019-03-25 20:31:06 +11:00
|
|
|
int index,
|
|
|
|
|
int value,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2019-03-25 20:31:06 +11:00
|
|
|
int icon,
|
|
|
|
|
const char *menu_type);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemEnumR_prop(uiLayout *layout,
|
|
|
|
|
std::optional<blender::StringRefNull> name,
|
|
|
|
|
int icon,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
int value);
|
2018-08-24 11:44:28 +10:00
|
|
|
void uiItemEnumR_string_prop(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2018-08-24 11:44:28 +10:00
|
|
|
const char *value,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2018-08-24 11:44:28 +10:00
|
|
|
int icon);
|
2010-11-17 09:45:45 +00:00
|
|
|
void uiItemEnumR_string(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2010-11-17 09:45:45 +00:00
|
|
|
const char *value,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2010-11-17 09:45:45 +00:00
|
|
|
int icon);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemsEnumR(uiLayout *layout, PointerRNA *ptr, blender::StringRefNull propname);
|
2018-08-24 11:44:28 +10:00
|
|
|
void uiItemPointerR_prop(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
PointerRNA *searchptr,
|
|
|
|
|
PropertyRNA *searchprop,
|
2024-12-06 14:08:10 +01:00
|
|
|
std::optional<blender::StringRefNull> name,
|
2022-04-04 03:50:55 +02:00
|
|
|
int icon,
|
|
|
|
|
bool results_are_suggestions);
|
2010-11-17 09:45:45 +00:00
|
|
|
void uiItemPointerR(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *ptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *searchptr,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull searchpropname,
|
|
|
|
|
std::optional<blender::StringRefNull> name,
|
2010-11-17 09:45:45 +00:00
|
|
|
int icon);
|
2023-10-11 19:27:02 +02:00
|
|
|
|
2023-10-12 09:22:34 +11:00
|
|
|
/**
|
2024-01-08 11:24:38 +11:00
|
|
|
* Create a list of enum items.
|
|
|
|
|
*
|
2023-10-12 09:22:34 +11:00
|
|
|
* \param active: an optional item to highlight.
|
2024-01-08 11:24:38 +11:00
|
|
|
*/
|
2016-02-16 14:50:26 +01:00
|
|
|
void uiItemsFullEnumO(uiLayout *layout,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
2023-08-04 22:15:25 -04:00
|
|
|
IDProperty *properties,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-10-11 19:27:02 +02:00
|
|
|
eUI_Item_Flag flag,
|
|
|
|
|
const int active = -1);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Create UI items for enum items in \a item_array.
|
|
|
|
|
*
|
|
|
|
|
* A version of #uiItemsFullEnumO that takes pre-calculated item array.
|
2023-10-12 09:22:34 +11:00
|
|
|
* \param active: if not -1, will highlight that item.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2016-02-16 14:50:26 +01:00
|
|
|
void uiItemsFullEnumO_items(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperatorType *ot,
|
2024-04-17 11:36:44 +10:00
|
|
|
const PointerRNA &ptr,
|
2023-08-04 22:15:25 -04:00
|
|
|
PropertyRNA *prop,
|
|
|
|
|
IDProperty *properties,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag,
|
2023-08-04 22:15:25 -04:00
|
|
|
const EnumPropertyItem *item_array,
|
2023-10-11 19:27:02 +02:00
|
|
|
int totitem,
|
|
|
|
|
int active = -1);
|
2010-11-17 09:45:45 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiPropertySplitWrapper {
|
2020-04-27 16:43:36 +02:00
|
|
|
uiLayout *label_column;
|
|
|
|
|
uiLayout *property_row;
|
2024-09-20 13:03:35 +02:00
|
|
|
/**
|
|
|
|
|
* Column for decorators. Note that this may be null, see #uiItemPropertySplitWrapperCreate().
|
|
|
|
|
*/
|
2020-04-27 16:43:36 +02:00
|
|
|
uiLayout *decorate_column;
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2020-04-27 16:43:36 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Normally, we handle the split layout in #uiItemFullR(), but there are other cases where the
|
|
|
|
|
* logic is needed. Ideally, #uiItemFullR() could just call this, but it currently has too many
|
|
|
|
|
* special needs.
|
2024-09-20 13:03:35 +02:00
|
|
|
*
|
|
|
|
|
* The returned #uiPropertySplitWrapper.decorator_column may be null when decorators are disabled
|
|
|
|
|
* (#uiLayoutGetPropDecorate() returns false).
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2020-04-27 16:43:36 +02:00
|
|
|
uiPropertySplitWrapper uiItemPropertySplitWrapperCreate(uiLayout *parent_layout);
|
|
|
|
|
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemL(uiLayout *layout, blender::StringRef name, int icon); /* label */
|
|
|
|
|
uiBut *uiItemL_ex(
|
|
|
|
|
uiLayout *layout, blender::StringRef name, int icon, bool highlight, bool redalert);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-09-20 12:29:14 +02:00
|
|
|
* Helper to add a label using a property split layout if needed. After calling this the
|
|
|
|
|
* active layout will be the one to place the labeled items in. An additional layout may be
|
|
|
|
|
* returned to place decorator buttons in.
|
|
|
|
|
*
|
|
|
|
|
* \return the layout to place decorators in, if #UI_ITEM_PROP_SEP is enabled. Otherwise null.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
uiLayout *uiItemL_respect_property_split(uiLayout *layout, blender::StringRef text, int icon);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Label icon for dragging.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemLDrag(uiLayout *layout, PointerRNA *ptr, blender::StringRef name, int icon);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Menu.
|
|
|
|
|
*/
|
2025-01-29 12:49:31 -05:00
|
|
|
void uiItemM_ptr(uiLayout *layout, MenuType *mt, std::optional<blender::StringRef> name, int icon);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemM(uiLayout *layout,
|
2025-02-04 13:53:30 +01:00
|
|
|
blender::StringRef menuname,
|
2025-01-29 12:49:31 -05:00
|
|
|
std::optional<blender::StringRef> name,
|
2024-12-06 14:08:10 +01:00
|
|
|
int icon);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Menu contents.
|
|
|
|
|
*/
|
2025-02-04 13:53:30 +01:00
|
|
|
void uiItemMContents(uiLayout *layout, blender::StringRef menuname);
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/* Decorators. */
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Insert a decorator item for a button with the same property as \a prop.
|
|
|
|
|
* To force inserting a blank dummy element, NULL can be passed for \a ptr and \a prop.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void uiItemDecoratorR_prop(uiLayout *layout, PointerRNA *ptr, PropertyRNA *prop, int index);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Insert a decorator item for a button with the same property as \a prop.
|
|
|
|
|
* To force inserting a blank dummy element, NULL can be passed for \a ptr and \a propname.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemDecoratorR(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
std::optional<blender::StringRefNull> propname,
|
|
|
|
|
int index);
|
2021-12-09 00:55:11 +11:00
|
|
|
/** Separator item */
|
2019-01-15 23:24:20 +11:00
|
|
|
void uiItemS(uiLayout *layout);
|
2021-12-09 00:55:11 +11:00
|
|
|
/** Separator item */
|
2024-02-09 17:38:36 +01:00
|
|
|
void uiItemS_ex(uiLayout *layout,
|
|
|
|
|
float factor,
|
|
|
|
|
LayoutSeparatorType type = LayoutSeparatorType::Auto);
|
2021-12-09 00:55:11 +11:00
|
|
|
/** Flexible spacing. */
|
2019-01-15 23:24:20 +11:00
|
|
|
void uiItemSpacer(uiLayout *layout);
|
2009-04-22 18:39:44 +00:00
|
|
|
|
2023-07-12 13:18:06 +10:00
|
|
|
void uiItemProgressIndicator(uiLayout *layout,
|
|
|
|
|
const char *text,
|
|
|
|
|
float factor,
|
|
|
|
|
enum eButProgressType progress_type);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/* popover */
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemPopoverPanel_ptr(uiLayout *layout,
|
|
|
|
|
const bContext *C,
|
|
|
|
|
PanelType *pt,
|
2025-02-04 13:53:30 +01:00
|
|
|
std::optional<blender::StringRef> name_opt,
|
2024-12-06 14:08:10 +01:00
|
|
|
int icon);
|
|
|
|
|
void uiItemPopoverPanel(uiLayout *layout,
|
|
|
|
|
const bContext *C,
|
2025-02-04 13:53:30 +01:00
|
|
|
blender::StringRef panel_type,
|
|
|
|
|
std::optional<blender::StringRef> name_opt,
|
2024-12-06 14:08:10 +01:00
|
|
|
int icon);
|
2018-04-22 17:16:39 +02:00
|
|
|
void uiItemPopoverPanelFromGroup(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
2018-04-22 17:16:39 +02:00
|
|
|
int space_id,
|
|
|
|
|
int region_id,
|
|
|
|
|
const char *context,
|
|
|
|
|
const char *category);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Level items.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemMenuF(
|
|
|
|
|
uiLayout *layout, blender::StringRefNull, int icon, uiMenuCreateFunc func, void *arg);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Version of #uiItemMenuF that free's `argN`.
|
|
|
|
|
*/
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemMenuFN(
|
|
|
|
|
uiLayout *layout, blender::StringRefNull, int icon, uiMenuCreateFunc func, void *argN);
|
2021-06-29 17:20:33 +02:00
|
|
|
void uiItemMenuEnumFullO_ptr(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
|
|
|
|
wmOperatorType *ot,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
std::optional<blender::StringRefNull> name,
|
2021-06-29 17:20:33 +02:00
|
|
|
int icon,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_opptr);
|
2021-06-29 17:20:33 +02:00
|
|
|
void uiItemMenuEnumFullO(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
blender::StringRefNull name,
|
2021-06-29 17:20:33 +02:00
|
|
|
int icon,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_opptr);
|
2013-05-10 23:41:41 +00:00
|
|
|
void uiItemMenuEnumO(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
const bContext *C,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
|
|
|
|
blender::StringRefNull propname,
|
|
|
|
|
blender::StringRefNull name,
|
2017-10-31 12:44:41 +11:00
|
|
|
int icon);
|
2024-12-06 14:08:10 +01:00
|
|
|
void uiItemMenuEnumR_prop(uiLayout *layout,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
std::optional<blender::StringRefNull>,
|
|
|
|
|
int icon);
|
2018-10-29 21:20:58 +01:00
|
|
|
void uiItemTabsEnumR_prop(uiLayout *layout,
|
2023-08-04 22:15:25 -04:00
|
|
|
bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
PointerRNA *ptr_highlight,
|
|
|
|
|
PropertyRNA *prop_highlight,
|
2018-10-29 21:20:58 +01:00
|
|
|
bool icon_only);
|
2009-03-13 13:38:41 +00:00
|
|
|
|
2020-09-01 15:23:55 +10:00
|
|
|
/* Only for testing, inspecting layouts. */
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Evaluate layout items as a Python dictionary.
|
|
|
|
|
*/
|
2020-09-01 15:23:55 +10:00
|
|
|
const char *UI_layout_introspect(uiLayout *layout);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-01-29 18:52:18 +01:00
|
|
|
* Helpers to add a big icon and create a split layout for alert popups.
|
2021-12-09 00:55:11 +11:00
|
|
|
* Returns the layout to place further items into the alert box.
|
|
|
|
|
*/
|
2024-01-29 18:52:18 +01:00
|
|
|
uiLayout *uiItemsAlertBox(uiBlock *block,
|
|
|
|
|
const uiStyle *style,
|
|
|
|
|
const int dialog_width,
|
|
|
|
|
const eAlertIcon icon,
|
|
|
|
|
const int icon_size);
|
|
|
|
|
uiLayout *uiItemsAlertBox(uiBlock *block, const int size, const eAlertIcon icon);
|
2020-12-06 11:17:51 -08:00
|
|
|
|
2009-12-17 10:47:55 +00:00
|
|
|
/* UI Operators */
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiDragColorHandle {
|
2025-01-30 12:37:15 +01:00
|
|
|
float color[4];
|
2014-07-21 12:02:05 +02:00
|
|
|
bool gamma_corrected;
|
2025-01-30 12:37:15 +01:00
|
|
|
bool has_alpha;
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2014-07-21 12:02:05 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void ED_operatortypes_ui();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \brief User Interface Keymap
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void ED_keymap_ui(wmKeyConfig *keyconf);
|
|
|
|
|
void ED_dropboxes_ui();
|
|
|
|
|
void ED_uilisttypes_ui();
|
2016-02-29 17:40:19 +01:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_drop_color_copy(bContext *C, wmDrag *drag, wmDropBox *drop);
|
|
|
|
|
bool UI_drop_color_poll(bContext *C, wmDrag *drag, const wmEvent *event);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_context_copy_to_selected_list(bContext *C,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
2024-03-27 00:47:39 +01:00
|
|
|
blender::Vector<PointerRNA> *r_lb,
|
2015-05-11 15:32:43 +10:00
|
|
|
bool *r_use_path_from_id,
|
2024-01-31 17:08:09 +01:00
|
|
|
std::optional<std::string> *r_path);
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_context_copy_to_selected_check(PointerRNA *ptr,
|
|
|
|
|
PointerRNA *ptr_link,
|
|
|
|
|
PropertyRNA *prop,
|
2021-12-16 13:03:39 +01:00
|
|
|
const char *path,
|
|
|
|
|
bool use_path_from_id,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_ptr,
|
|
|
|
|
PropertyRNA **r_prop);
|
2015-05-11 15:32:43 +10:00
|
|
|
|
2009-07-28 18:51:06 +00:00
|
|
|
/* Helpers for Operators */
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBut *UI_context_active_but_get(const bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-05-10 11:25:44 +10:00
|
|
|
* Version of #UI_context_active_get() that uses the result of #CTX_wm_region_popup() if set.
|
|
|
|
|
* Does not traverse into parent menus, which may be wanted in some cases.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-05-10 11:25:44 +10:00
|
|
|
uiBut *UI_context_active_but_get_respect_popup(const bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Version of #UI_context_active_but_get that also returns RNA property info.
|
|
|
|
|
* Helper function for insert keyframe, reset to default, etc operators.
|
|
|
|
|
*
|
|
|
|
|
* \return active button, NULL if none found or if it doesn't contain valid RNA data.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBut *UI_context_active_but_prop_get(const bContext *C,
|
|
|
|
|
PointerRNA *r_ptr,
|
|
|
|
|
PropertyRNA **r_prop,
|
2016-06-24 10:05:09 +10:00
|
|
|
int *r_index);
|
2023-03-14 16:27:23 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* As above, but for a specified region.
|
|
|
|
|
*
|
|
|
|
|
* \return active button, NULL if none found or if it doesn't contain valid RNA data.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBut *UI_region_active_but_prop_get(const ARegion *region,
|
|
|
|
|
PointerRNA *r_ptr,
|
|
|
|
|
PropertyRNA **r_prop,
|
2023-03-14 16:27:23 +01:00
|
|
|
int *r_index);
|
|
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_context_active_but_prop_handle(bContext *C, bool handle_undo);
|
|
|
|
|
void UI_context_active_but_clear(bContext *C, wmWindow *win, ARegion *region);
|
2020-05-20 22:04:59 +10:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
wmOperator *UI_context_active_operator_get(const bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Helper function for insert keyframe, reset to default, etc operators.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_context_update_anim_flag(const bContext *C);
|
|
|
|
|
void UI_context_active_but_prop_get_filebrowser(const bContext *C,
|
|
|
|
|
PointerRNA *r_ptr,
|
|
|
|
|
PropertyRNA **r_prop,
|
2020-06-11 17:24:00 +10:00
|
|
|
bool *r_is_undo,
|
|
|
|
|
bool *r_is_userdef);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For new/open operators.
|
2023-03-29 14:16:31 +11:00
|
|
|
*
|
|
|
|
|
* This is for browsing and editing the ID-blocks used.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-08-23 11:07:16 +02:00
|
|
|
void UI_context_active_but_prop_get_templateID(const bContext *C,
|
2023-08-04 22:15:25 -04:00
|
|
|
PointerRNA *r_ptr,
|
|
|
|
|
PropertyRNA **r_prop);
|
|
|
|
|
ID *UI_context_active_but_get_tab_ID(bContext *C);
|
2009-04-03 23:30:32 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
uiBut *UI_region_active_but_get(const ARegion *region);
|
|
|
|
|
uiBut *UI_region_but_find_rect_over(const ARegion *region, const rcti *rect_px);
|
|
|
|
|
uiBlock *UI_region_block_find_mouse_over(const ARegion *region, const int xy[2], bool only_clip);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Try to find a search-box region opened from a button in \a button_region.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
ARegion *UI_region_searchbox_region_get(const ARegion *button_region);
|
2018-01-25 16:17:25 +11:00
|
|
|
|
2022-04-05 08:00:20 +10:00
|
|
|
/** #uiFontStyle.align */
|
2023-08-04 22:15:25 -04:00
|
|
|
enum eFontStyle_Align {
|
2019-01-04 09:58:03 +11:00
|
|
|
UI_STYLE_TEXT_LEFT = 0,
|
|
|
|
|
UI_STYLE_TEXT_CENTER = 1,
|
2019-01-15 23:57:49 +11:00
|
|
|
UI_STYLE_TEXT_RIGHT = 2,
|
2023-08-04 22:15:25 -04:00
|
|
|
};
|
2019-01-04 09:58:03 +11:00
|
|
|
|
|
|
|
|
struct uiFontStyleDraw_Params {
|
|
|
|
|
eFontStyle_Align align;
|
|
|
|
|
uint word_wrap : 1;
|
|
|
|
|
};
|
|
|
|
|
|
2009-04-09 18:11:18 +00:00
|
|
|
/* Styled text draw */
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_fontstyle_set(const uiFontStyle *fs);
|
|
|
|
|
void UI_fontstyle_draw_ex(const uiFontStyle *fs,
|
|
|
|
|
const rcti *rect,
|
2015-01-20 14:25:39 +11:00
|
|
|
const char *str,
|
2022-01-12 12:49:36 +01:00
|
|
|
size_t str_len,
|
2019-01-04 09:58:03 +11:00
|
|
|
const uchar col[4],
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiFontStyleDraw_Params *fs_params,
|
2020-04-14 18:41:23 +10:00
|
|
|
int *r_xofs,
|
2020-04-14 18:46:13 +10:00
|
|
|
int *r_yofs,
|
2023-08-04 22:15:25 -04:00
|
|
|
ResultBLF *r_info);
|
2022-01-12 12:49:36 +01:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_fontstyle_draw(const uiFontStyle *fs,
|
|
|
|
|
const rcti *rect,
|
2018-07-09 06:40:47 +02:00
|
|
|
const char *str,
|
2022-01-12 12:49:36 +01:00
|
|
|
size_t str_len,
|
2019-01-04 09:58:03 +11:00
|
|
|
const uchar col[4],
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiFontStyleDraw_Params *fs_params);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2024-06-23 12:14:19 +10:00
|
|
|
* Drawn same as #UI_fontstyle_draw, but at 90 degree angle.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_fontstyle_draw_rotated(const uiFontStyle *fs,
|
|
|
|
|
const rcti *rect,
|
2018-07-09 06:40:47 +02:00
|
|
|
const char *str,
|
2019-01-04 09:58:03 +11:00
|
|
|
const uchar col[4]);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Similar to #UI_fontstyle_draw
|
|
|
|
|
* but ignore alignment, shadow & no clipping rect.
|
|
|
|
|
*
|
|
|
|
|
* For drawing on-screen labels.
|
|
|
|
|
*/
|
2018-07-09 06:40:47 +02:00
|
|
|
void UI_fontstyle_draw_simple(
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiFontStyle *fs, float x, float y, const char *str, const uchar col[4]);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Same as #UI_fontstyle_draw but draw a colored backdrop.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_fontstyle_draw_simple_backdrop(const uiFontStyle *fs,
|
2015-07-11 02:49:04 +10:00
|
|
|
float x,
|
|
|
|
|
float y,
|
2024-01-19 10:45:33 -05:00
|
|
|
blender::StringRef str,
|
2016-11-22 14:40:57 +01:00
|
|
|
const float col_fg[4],
|
|
|
|
|
const float col_bg[4]);
|
2009-04-09 18:11:18 +00:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_fontstyle_string_width(const uiFontStyle *fs, const char *str) ATTR_WARN_UNUSED_RESULT
|
|
|
|
|
ATTR_NONNULL(1, 2);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Return the width of `str` with the spacing & kerning of `fs` with `aspect`
|
|
|
|
|
* (representing #uiBlock.aspect) applied.
|
|
|
|
|
*
|
|
|
|
|
* When calculating text width, the UI layout logic calculate widths without scale,
|
|
|
|
|
* only applying scale when drawing. This causes problems for fonts since kerning at
|
|
|
|
|
* smaller sizes often makes them wider than a scaled down version of the larger text.
|
|
|
|
|
* Resolve this by calculating the text at the on-screen size,
|
2023-02-12 14:37:16 +11:00
|
|
|
* returning the result scaled back to 1:1. See #92361.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_fontstyle_string_width_with_block_aspect(const uiFontStyle *fs,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRef str,
|
2022-01-07 11:38:08 +11:00
|
|
|
float aspect) ATTR_WARN_UNUSED_RESULT
|
2024-12-06 14:08:10 +01:00
|
|
|
ATTR_NONNULL(1);
|
2023-08-04 22:15:25 -04:00
|
|
|
int UI_fontstyle_height_max(const uiFontStyle *fs);
|
2015-01-20 15:48:40 +11:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Triangle 'icon' for panel header and other cases.
|
|
|
|
|
*/
|
2017-02-14 13:00:22 +01:00
|
|
|
void UI_draw_icon_tri(float x, float y, char dir, const float[4]);
|
Holiday coding log :)
Nice formatted version (pictures soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability
Short list of main changes:
- Transparent region option (over main region), added code to blend in/out such panels.
- Min size window now 640 x 480
- Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake.
- Macbook retina support, use command line --no-native-pixels to disable it
- Timeline Marker label was drawing wrong
- Trackpad and magic mouse: supports zoom (hold ctrl)
- Fix for splash position: removed ghost function and made window size update after creation immediate
- Fast undo buffer save now adds UI as well. Could be checked for regular file save even...
Quit.blend and temp file saving use this now.
- Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)"
- New Userpref option "Keep Session" - this always saves quit.blend, and loads on start.
This allows keeping UI and data without actual saves, until you actually save.
When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header)
- Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v).
Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards.
- User preferences (themes, keymaps, user settings) now can be saved as a separate file.
Old option is called "Save Startup File" the new one "Save User Settings".
To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still.
- OSX: fixed bug that stopped giving mouse events outside window.
This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* Read a style (without any scaling applied).
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiStyle *UI_style_get(); /* use for fonts etc */
|
2023-07-26 15:23:24 +10:00
|
|
|
/**
|
|
|
|
|
* Read a style (with the current DPI applied).
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
const uiStyle *UI_style_get_dpi();
|
Holiday coding log :)
Nice formatted version (pictures soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability
Short list of main changes:
- Transparent region option (over main region), added code to blend in/out such panels.
- Min size window now 640 x 480
- Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake.
- Macbook retina support, use command line --no-native-pixels to disable it
- Timeline Marker label was drawing wrong
- Trackpad and magic mouse: supports zoom (hold ctrl)
- Fix for splash position: removed ghost function and made window size update after creation immediate
- Fast undo buffer save now adds UI as well. Could be checked for regular file save even...
Quit.blend and temp file saving use this now.
- Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)"
- New Userpref option "Keep Session" - this always saves quit.blend, and loads on start.
This allows keeping UI and data without actual saves, until you actually save.
When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header)
- Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v).
Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards.
- User preferences (themes, keymaps, user settings) now can be saved as a separate file.
Old option is called "Save Startup File" the new one "Save User Settings".
To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still.
- OSX: fixed bug that stopped giving mouse events outside window.
This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
|
|
|
|
2011-10-23 04:13:56 +00:00
|
|
|
/* UI_OT_editsource helpers */
|
2023-08-04 22:15:25 -04:00
|
|
|
bool UI_editsource_enable_check();
|
2011-10-23 04:13:56 +00:00
|
|
|
void UI_editsource_active_but_test(uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Remove the editsource data for \a old_but and reinsert it for \a new_but. Use when the button
|
|
|
|
|
* was reallocated, e.g. to have a new type (#ui_but_change_type()).
|
|
|
|
|
*/
|
2021-02-18 16:33:00 +01:00
|
|
|
void UI_editsource_but_replace(const uiBut *old_but, uiBut *new_but);
|
2011-10-23 04:13:56 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Adjust the view so the rectangle of \a but is in view, with some extra margin.
|
|
|
|
|
*
|
|
|
|
|
* It's important that this is only executed after buttons received their final #uiBut.rect. E.g.
|
|
|
|
|
* #UI_panels_end() modifies them, so if that is executed, this function must not be called before
|
|
|
|
|
* it.
|
|
|
|
|
*
|
|
|
|
|
* \param region: The region the button is placed in. Make sure this is actually the one the button
|
|
|
|
|
* is placed in, not just the context region.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_but_ensure_in_view(const bContext *C, ARegion *region, const uiBut *but);
|
2021-07-13 17:06:15 +02:00
|
|
|
|
2014-02-08 09:03:25 +11:00
|
|
|
/* UI_butstore_ helpers */
|
2023-08-04 22:15:25 -04:00
|
|
|
struct uiButStore;
|
2014-02-08 09:03:25 +11:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Create a new button store, the caller must manage and run #UI_butstore_free
|
|
|
|
|
*/
|
2014-02-08 09:03:25 +11:00
|
|
|
uiButStore *UI_butstore_create(uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* NULL all pointers, don't free since the owner needs to be able to inspect.
|
|
|
|
|
*/
|
2014-02-08 09:03:25 +11:00
|
|
|
void UI_butstore_clear(uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Map freed buttons from the old block and update pointers.
|
|
|
|
|
*/
|
2014-02-08 09:03:25 +11:00
|
|
|
void UI_butstore_update(uiBlock *block);
|
2024-07-27 13:20:43 +10:00
|
|
|
void UI_butstore_free(uiBlock *block, uiButStore *bs_handle);
|
|
|
|
|
bool UI_butstore_is_valid(uiButStore *bs_handle);
|
2014-02-08 09:03:25 +11:00
|
|
|
bool UI_butstore_is_registered(uiBlock *block, uiBut *but);
|
|
|
|
|
void UI_butstore_register(uiButStore *bs_handle, uiBut **but_p);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Update the pointer for a registered button.
|
|
|
|
|
*/
|
2014-12-01 23:30:54 +01:00
|
|
|
bool UI_butstore_register_update(uiBlock *block, uiBut *but_dst, const uiBut *but_src);
|
2014-02-08 09:03:25 +11:00
|
|
|
void UI_butstore_unregister(uiButStore *bs_handle, uiBut **but_p);
|
|
|
|
|
|
2023-01-11 19:14:35 +11:00
|
|
|
/**
|
|
|
|
|
* A version of #WM_key_event_operator_string that's limited to UI elements.
|
|
|
|
|
*
|
|
|
|
|
* This supports showing shortcuts in context-menus (for example),
|
|
|
|
|
* for actions that can also be activated using shortcuts while the cursor is over the button.
|
|
|
|
|
* Without this those shortcuts aren't discoverable for users.
|
|
|
|
|
*/
|
2024-02-07 14:22:54 +01:00
|
|
|
std::optional<std::string> UI_key_event_operator_string(const bContext *C,
|
2024-12-06 14:08:10 +01:00
|
|
|
blender::StringRefNull opname,
|
2024-02-07 14:22:54 +01:00
|
|
|
IDProperty *properties,
|
|
|
|
|
bool is_strict);
|
2023-01-11 19:14:35 +11:00
|
|
|
|
2017-12-20 14:50:39 +11:00
|
|
|
/* ui_interface_region_tooltip.c */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* \param is_label: When true, show a small tip that only shows the name, otherwise show the full
|
|
|
|
|
* tooltip.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
ARegion *UI_tooltip_create_from_button(bContext *C, ARegion *butregion, uiBut *but, bool is_label);
|
|
|
|
|
ARegion *UI_tooltip_create_from_button_or_extra_icon(
|
|
|
|
|
bContext *C, ARegion *butregion, uiBut *but, uiButExtraOpIcon *extra_icon, bool is_label);
|
|
|
|
|
ARegion *UI_tooltip_create_from_gizmo(bContext *C, wmGizmo *gz);
|
|
|
|
|
void UI_tooltip_free(bContext *C, bScreen *screen, ARegion *region);
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Create a tooltip from search-item tooltip data \a item_tooltip data.
|
|
|
|
|
* To be called from a callback set with #UI_but_func_search_set_tooltip().
|
|
|
|
|
*
|
|
|
|
|
* \param item_rect: Rectangle of the search item in search region space (#ui_searchbox_butrect())
|
|
|
|
|
* which is passed to the tooltip callback.
|
|
|
|
|
*/
|
2024-06-08 22:41:58 +02:00
|
|
|
ARegion *UI_tooltip_create_from_search_item_generic(bContext *C,
|
|
|
|
|
const ARegion *searchbox_region,
|
|
|
|
|
const rcti *item_rect,
|
|
|
|
|
ID *id);
|
2021-01-26 22:06:45 +01:00
|
|
|
|
2017-12-20 14:50:39 +11:00
|
|
|
/* How long before a tool-tip shows. */
|
|
|
|
|
#define UI_TOOLTIP_DELAY 0.5
|
2018-09-06 14:19:15 +10:00
|
|
|
#define UI_TOOLTIP_DELAY_LABEL 0.2
|
2014-02-08 09:03:25 +11:00
|
|
|
|
2014-01-08 17:04:10 +01:00
|
|
|
/* Float precision helpers */
|
2017-07-21 10:10:36 +02:00
|
|
|
#define UI_PRECISION_FLOAT_MAX 6
|
2024-02-29 22:38:42 -05:00
|
|
|
/* For float buttons the 'step', is scaled */
|
2015-09-17 21:50:40 +10:00
|
|
|
#define UI_PRECISION_FLOAT_SCALE 0.01f
|
2014-01-08 17:04:10 +01:00
|
|
|
|
2015-01-20 14:25:39 +11:00
|
|
|
/* Typical UI text */
|
|
|
|
|
#define UI_FSTYLE_WIDGET (const uiFontStyle *)&(UI_style_get()->widget)
|
2024-09-04 22:43:57 +02:00
|
|
|
#define UI_FSTYLE_TOOLTIP (const uiFontStyle *)&(UI_style_get()->tooltip)
|
2015-01-20 14:25:39 +11:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Returns the best "UI" precision for given floating value,
|
|
|
|
|
* so that e.g. 10.000001 rather gets drawn as '10'...
|
|
|
|
|
*/
|
2014-11-09 21:20:40 +01:00
|
|
|
int UI_calc_float_precision(int prec, double value);
|
2014-01-08 17:04:10 +01:00
|
|
|
|
2018-04-06 14:25:55 +02:00
|
|
|
/* widget batched drawing */
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_widgetbase_draw_cache_begin();
|
|
|
|
|
void UI_widgetbase_draw_cache_flush();
|
|
|
|
|
void UI_widgetbase_draw_cache_end();
|
2018-04-06 14:25:55 +02:00
|
|
|
|
2019-03-02 00:52:00 +11:00
|
|
|
/* Use for resetting the theme. */
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Initialize default theme.
|
|
|
|
|
*
|
|
|
|
|
* \note When you add new colors, created & saved themes need initialized
|
|
|
|
|
* use function below, #init_userdef_do_versions.
|
|
|
|
|
*/
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_theme_init_default();
|
|
|
|
|
void UI_style_init_default();
|
2019-03-02 00:52:00 +11:00
|
|
|
|
2023-08-04 22:15:25 -04:00
|
|
|
void UI_interface_tag_script_reload();
|
2019-10-01 01:59:31 +10:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Special drawing for toolbar, mainly workarounds for inflexible icon sizing. */
|
2018-06-06 09:27:23 +02:00
|
|
|
#define USE_UI_TOOLBAR_HACK
|
2018-04-25 21:01:36 +02:00
|
|
|
|
2023-07-26 15:23:24 +10:00
|
|
|
/** Support click-drag motion which presses the button and closes a popover (like a menu). */
|
2018-06-06 09:27:23 +02:00
|
|
|
#define USE_UI_POPOVER_ONCE
|
2018-05-19 19:16:47 +02:00
|
|
|
|
2024-03-08 09:16:00 -05:00
|
|
|
bool UI_view_item_matches(const blender::ui::AbstractViewItem &a,
|
|
|
|
|
const blender::ui::AbstractViewItem &b);
|
2023-06-12 11:41:00 +02:00
|
|
|
/**
|
2024-03-08 09:16:00 -05:00
|
|
|
* Can \a item be renamed right now? Note that this isn't just a mere wrapper around
|
UI: Port view item features to base class, merge view item button types
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
|
|
|
* #AbstractViewItem::supports_renaming(). This also checks if there is another item being renamed,
|
|
|
|
|
* and returns false if so.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-03-08 09:16:00 -05:00
|
|
|
bool UI_view_item_can_rename(const blender::ui::AbstractViewItem &item);
|
|
|
|
|
void UI_view_item_begin_rename(blender::ui::AbstractViewItem &item);
|
UI: Port view item features to base class, merge view item button types
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
|
|
|
|
2024-03-08 09:16:00 -05:00
|
|
|
bool UI_view_item_supports_drag(const blender::ui::AbstractViewItem &item);
|
2024-07-02 16:12:33 +02:00
|
|
|
/** If this view is displayed in a popup, don't close it when clicking to activate items. */
|
|
|
|
|
bool UI_view_item_popup_keep_open(const blender::ui::AbstractViewItem &item);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
UI: Port view item features to base class, merge view item button types
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
|
|
|
* Attempt to start dragging \a item_. This will not work if the view item doesn't
|
|
|
|
|
* support dragging, i.e. if it won't create a drag-controller upon request.
|
|
|
|
|
* \return True if dragging started successfully, otherwise false.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-03-08 09:16:00 -05:00
|
|
|
bool UI_view_item_drag_start(bContext &C, const blender::ui::AbstractViewItem &item);
|
2023-03-22 18:45:35 +01:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2023-03-22 18:45:35 +01:00
|
|
|
* \param xy: Coordinate to find a view item at, in window space.
|
|
|
|
|
* \param pad: Extra padding added to the bounding box of the view.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-03-08 09:16:00 -05:00
|
|
|
blender::ui::AbstractView *UI_region_view_find_at(const ARegion *region, const int xy[2], int pad);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
UI: Port view item features to base class, merge view item button types
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
|
|
|
* \param xy: Coordinate to find a view item at, in window space.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2024-03-08 09:16:00 -05:00
|
|
|
blender::ui::AbstractViewItem *UI_region_views_find_item_at(const ARegion ®ion,
|
|
|
|
|
const int xy[2]);
|
|
|
|
|
blender::ui::AbstractViewItem *UI_region_views_find_active_item(const ARegion *region);
|
2024-05-07 17:27:45 +02:00
|
|
|
uiBut *UI_region_views_find_active_item_but(const ARegion *region);
|
2024-07-01 20:21:25 +02:00
|
|
|
void UI_region_views_clear_search_highlight(const ARegion *region);
|