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 edinterface
|
2011-02-27 20:29:51 +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-06-05 14:21:39 +02:00
|
|
|
#include <functional>
|
|
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
#include "BLI_compiler_attrs.h"
|
2023-09-26 17:12:37 +02:00
|
|
|
#include "BLI_math_vector_types.hh"
|
2024-01-22 14:54:44 -05:00
|
|
|
#include "BLI_string_ref.hh"
|
2022-12-18 21:45:32 -06:00
|
|
|
#include "BLI_vector.hh"
|
2020-05-12 12:02:28 +10:00
|
|
|
|
2024-04-29 18:34:57 +02:00
|
|
|
#include "BKE_fcurve.hh"
|
|
|
|
|
|
2014-11-06 20:19:21 +01:00
|
|
|
#include "DNA_listBase.h"
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_types.hh"
|
2023-08-05 02:57:52 +02:00
|
|
|
#include "UI_interface.hh"
|
|
|
|
|
#include "UI_resources.hh"
|
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
|
|
|
|
2020-09-30 11:51:13 +10:00
|
|
|
struct AnimationEvalContext;
|
2022-11-26 00:21:17 -06:00
|
|
|
struct ARegion;
|
|
|
|
|
struct bContext;
|
|
|
|
|
struct bContextStore;
|
2020-08-13 21:33:47 -04:00
|
|
|
struct CurveMapping;
|
2020-08-13 21:00:54 -04:00
|
|
|
struct CurveProfile;
|
2024-03-26 03:06:25 +01:00
|
|
|
namespace blender::gpu {
|
|
|
|
|
class Batch;
|
|
|
|
|
}
|
2022-10-20 16:37:07 +02:00
|
|
|
struct IconTextOverlay;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct ID;
|
|
|
|
|
struct ImBuf;
|
2024-05-24 20:29:37 +02:00
|
|
|
struct LayoutPanelHeader;
|
2022-08-17 12:10:31 +02:00
|
|
|
struct Main;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Scene;
|
2008-12-16 07:55:43 +00:00
|
|
|
struct uiHandleButtonData;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiLayout;
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiListType;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiStyle;
|
2020-05-12 10:55:46 +10:00
|
|
|
struct uiUndoStack_Text;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiWidgetColors;
|
2022-11-26 00:21:17 -06:00
|
|
|
struct UnitSettings;
|
2008-12-26 13:11:04 +00:00
|
|
|
struct wmEvent;
|
2016-02-29 18:46:20 +01:00
|
|
|
struct wmKeyConfig;
|
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
|
|
|
struct wmOperatorType;
|
Code holiday commit:
- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
2011-06-04 17:03:46 +00:00
|
|
|
struct wmTimer;
|
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
|
|
|
|
Refactor: OpenColorIO integration
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
2025-05-09 14:01:43 +02:00
|
|
|
namespace blender::ocio {
|
|
|
|
|
class Display;
|
|
|
|
|
} // namespace blender::ocio
|
|
|
|
|
using ColorManagedDisplay = blender::ocio::Display;
|
|
|
|
|
|
2009-04-07 17:08:26 +00:00
|
|
|
/* ****************** general defines ************** */
|
|
|
|
|
|
2013-11-23 18:43:23 +01:00
|
|
|
#define RNA_NO_INDEX -1
|
|
|
|
|
#define RNA_ENUM_VALUE -2
|
|
|
|
|
|
2019-03-18 17:41:37 +11:00
|
|
|
#define UI_MENU_PADDING (int)(0.2f * UI_UNIT_Y)
|
|
|
|
|
|
2018-07-06 19:26:12 +02:00
|
|
|
#define UI_MENU_WIDTH_MIN (UI_UNIT_Y * 9)
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Some extra padding added to menus containing sub-menu icons. */
|
2023-03-17 04:19:05 +01:00
|
|
|
#define UI_MENU_SUBMENU_PADDING (6 * UI_SCALE_FAC)
|
2018-04-25 21:54:29 +02:00
|
|
|
|
2012-10-31 12:56:04 +00:00
|
|
|
/* menu scrolling */
|
2023-03-17 04:19:05 +01:00
|
|
|
#define UI_MENU_SCROLL_ARROW (12 * UI_SCALE_FAC)
|
|
|
|
|
#define UI_MENU_SCROLL_MOUSE (UI_MENU_SCROLL_ARROW + 2 * UI_SCALE_FAC)
|
|
|
|
|
#define UI_MENU_SCROLL_PAD (4 * UI_SCALE_FAC)
|
2012-10-31 12:56:04 +00:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Popover width (multiplied by #U.widget_unit) */
|
2018-04-22 23:03:08 +02:00
|
|
|
#define UI_POPOVER_WIDTH_UNITS 10
|
|
|
|
|
|
2021-04-21 00:51:27 +10:00
|
|
|
/** #uiBut.flag */
|
2013-11-21 14:43:08 +01:00
|
|
|
enum {
|
2021-04-21 00:51:27 +10:00
|
|
|
/** Use when the button is pressed. */
|
|
|
|
|
UI_SELECT = (1 << 0),
|
|
|
|
|
/** Temporarily hidden (scrolled out of the view). */
|
|
|
|
|
UI_SCROLLED = (1 << 1),
|
2023-10-25 18:36:27 +02:00
|
|
|
/**
|
|
|
|
|
* The button is hovered by the mouse and should be drawn with a hover highlight. Also set
|
|
|
|
|
* sometimes to highlight buttons without actually hovering it (e.g. for arrow navigation in
|
|
|
|
|
* menus). UI handling code manages this mostly and usually does this together with making the
|
|
|
|
|
* button active/focused (see #uiBut::active). This means events will be forwarded to it and
|
|
|
|
|
* further handlers/shortcuts can be used while hovering it.
|
|
|
|
|
*/
|
|
|
|
|
UI_HOVER = (1 << 2),
|
2013-11-21 14:43:08 +01:00
|
|
|
UI_HAS_ICON = (1 << 3),
|
2017-11-03 00:22:59 +11:00
|
|
|
UI_HIDDEN = (1 << 4),
|
2021-04-21 00:51:27 +10:00
|
|
|
/** Display selected, doesn't impact interaction. */
|
|
|
|
|
UI_SELECT_DRAW = (1 << 5),
|
|
|
|
|
/** Property search filter is active and the button does not match. */
|
2021-04-20 15:44:21 +10:00
|
|
|
UI_SEARCH_FILTER_NO_MATCH = (1 << 6),
|
2022-05-13 15:55:11 +02:00
|
|
|
|
|
|
|
|
/** Temporarily override the active button for lookups in context, regions, etc. (everything
|
|
|
|
|
* using #ui_context_button_active()). For example, so that operators normally acting on the
|
|
|
|
|
* active button can be polled on non-active buttons to (e.g. for disabling). */
|
|
|
|
|
UI_BUT_ACTIVE_OVERRIDE = (1 << 7),
|
|
|
|
|
|
2025-04-23 05:29:14 +00:00
|
|
|
/* WARNING: rest of #uiBut.flag in `UI_interface_c.hh`. */
|
2013-11-21 14:43:08 +01: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
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #uiBut.pie_dir */
|
2022-11-26 00:21:17 -06:00
|
|
|
enum RadialDirection {
|
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_RADIAL_NONE = -1,
|
|
|
|
|
UI_RADIAL_N = 0,
|
|
|
|
|
UI_RADIAL_NE = 1,
|
|
|
|
|
UI_RADIAL_E = 2,
|
|
|
|
|
UI_RADIAL_SE = 3,
|
|
|
|
|
UI_RADIAL_S = 4,
|
|
|
|
|
UI_RADIAL_SW = 5,
|
|
|
|
|
UI_RADIAL_W = 6,
|
|
|
|
|
UI_RADIAL_NW = 7,
|
2022-11-26 00:21:17 -06: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
|
|
|
|
2023-09-13 12:25:04 +10:00
|
|
|
/** Next direction (clockwise). */
|
|
|
|
|
#define UI_RADIAL_DIRECTION_NEXT(dir) RadialDirection((int(dir) + 1) % (int(UI_RADIAL_NW) + 1))
|
|
|
|
|
/** Previous direction (counter-clockwise). */
|
|
|
|
|
#define UI_RADIAL_DIRECTION_PREV(dir) \
|
|
|
|
|
RadialDirection(((int(dir) + int(UI_RADIAL_NW))) % (int(UI_RADIAL_NW) + 1))
|
|
|
|
|
|
2023-09-14 16:10:36 +10:00
|
|
|
/** Store a mask for diagonal directions. */
|
|
|
|
|
#define UI_RADIAL_MASK_ALL_DIAGONAL \
|
|
|
|
|
((1 << int(UI_RADIAL_NE)) | (1 << int(UI_RADIAL_SE)) | (1 << int(UI_RADIAL_SW)) | \
|
|
|
|
|
(1 << int(UI_RADIAL_NW)))
|
|
|
|
|
#define UI_RADIAL_MASK_ALL_AXIS_ALIGNED \
|
|
|
|
|
((1 << int(UI_RADIAL_N)) | (1 << int(UI_RADIAL_S)) | (1 << int(UI_RADIAL_E)) | \
|
|
|
|
|
(1 << int(UI_RADIAL_W)))
|
|
|
|
|
|
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
|
|
|
extern const char ui_radial_dir_order[8];
|
|
|
|
|
extern const char ui_radial_dir_to_numpad[8];
|
|
|
|
|
extern const short ui_radial_dir_to_angle[8];
|
|
|
|
|
|
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
|
|
|
/* internal panel drawing defines */
|
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 PNL_HEADER (UI_UNIT_Y * 1.25) /* 24 default */
|
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
|
|
|
|
2012-09-03 10:12:25 +00:00
|
|
|
/* bit button defines */
|
|
|
|
|
/* Bit operations */
|
2019-03-25 16:17:39 +11:00
|
|
|
#define UI_BITBUT_TEST(a, b) (((a) & (1 << (b))) != 0)
|
|
|
|
|
#define UI_BITBUT_VALUE_TOGGLED(a, b) ((a) ^ (1 << (b)))
|
|
|
|
|
#define UI_BITBUT_VALUE_ENABLED(a, b) ((a) | (1 << (b)))
|
|
|
|
|
#define UI_BITBUT_VALUE_DISABLED(a, b) ((a) & ~(1 << (b)))
|
|
|
|
|
|
2012-09-03 10:12:25 +00:00
|
|
|
/* bit-row */
|
2015-08-02 13:54:06 +10:00
|
|
|
#define UI_BITBUT_ROW(min, max) \
|
|
|
|
|
(((max) >= 31 ? 0xFFFFFFFF : (1 << ((max) + 1)) - 1) - ((min) ? ((1 << (min)) - 1) : 0))
|
2012-09-03 10:12:25 +00:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Split number-buttons by ':' and align left/right. */
|
2013-12-11 21:27:13 +11:00
|
|
|
#define USE_NUMBUTS_LR_ALIGN
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Use new 'align' computation code. */
|
2015-11-06 18:39:56 +01:00
|
|
|
#define USE_UIBUT_SPATIAL_ALIGN
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #PieMenuData.flags */
|
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
|
|
|
enum {
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Use initial center of pie menu to calculate direction. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_INITIAL_DIRECTION = (1 << 1),
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Pie menu is drag style. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_DRAG_STYLE = (1 << 2),
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Mouse not far enough from center position. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_INVALID_DIR = (1 << 3),
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Pie menu changed to click style, click to confirm. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_CLICK_STYLE = (1 << 4),
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Pie animation finished, do not calculate any more motion. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_ANIMATION_FINISHED = (1 << 5),
|
2021-06-24 15:56:58 +10:00
|
|
|
/** Pie gesture selection has been done, now wait for mouse motion to end. */
|
2019-01-15 23:24:20 +11:00
|
|
|
UI_PIE_GESTURE_END_WAIT = (1 << 6),
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define PIE_CLICK_THRESHOLD_SQ 50.0f
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** The maximum number of items a radial menu (pie menu) can contain. */
|
2016-02-16 14:50:26 +01:00
|
|
|
#define PIE_MAX_ITEMS 8
|
|
|
|
|
|
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 uiBut {
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Pointer back to the layout item holding this button. */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiLayout *layout = nullptr;
|
|
|
|
|
int flag = 0;
|
2023-09-06 18:16:45 +02:00
|
|
|
int flag2 = 0;
|
2023-02-03 16:12:14 +01:00
|
|
|
int drawflag = 0;
|
|
|
|
|
eButType type = eButType(0);
|
|
|
|
|
eButPointerType pointype = UI_BUT_POIN_NONE;
|
|
|
|
|
short bit = 0, bitnr = 0, retval = 0, strwidth = 0, alignnr = 0;
|
|
|
|
|
short ofs = 0, pos = 0, selsta = 0, selend = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2024-01-16 21:04:17 +01:00
|
|
|
std::string str;
|
|
|
|
|
|
2024-01-22 14:54:44 -05:00
|
|
|
std::string drawstr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-10-12 11:44:08 -07:00
|
|
|
char *placeholder = nullptr;
|
|
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/** Block relative coordinates. */
|
|
|
|
|
rctf rect = {};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
char *poin = nullptr;
|
|
|
|
|
float hardmin = 0, hardmax = 0, softmin = 0, softmax = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2024-08-30 20:52:17 +02:00
|
|
|
/**
|
|
|
|
|
* Optional color for monochrome icon. Also used as text
|
|
|
|
|
* color for labels without icons. Set with #UI_but_color_set().
|
|
|
|
|
*/
|
2023-02-03 16:12:14 +01:00
|
|
|
uchar col[4] = {0};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-04-26 22:26:15 +02:00
|
|
|
/** See \ref UI_but_func_identity_compare_set(). */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButIdentityCompareFunc identity_cmp_func = nullptr;
|
2022-04-26 22:26:15 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButHandleFunc func = nullptr;
|
|
|
|
|
void *func_arg1 = nullptr;
|
|
|
|
|
void *func_arg2 = nullptr;
|
2023-06-26 16:39:51 +02:00
|
|
|
/**
|
|
|
|
|
* C++ version of #func above. Allows storing arbitrary data in a type safe way, no void
|
|
|
|
|
* pointer arguments.
|
|
|
|
|
*/
|
|
|
|
|
std::function<void(bContext &)> apply_func;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButHandleNFunc funcN = nullptr;
|
|
|
|
|
void *func_argN = nullptr;
|
2024-07-05 17:09:40 +02:00
|
|
|
uiButArgNFree func_argN_free_fn;
|
|
|
|
|
uiButArgNCopy func_argN_copy_fn;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-08-31 11:59:58 -04:00
|
|
|
const bContextStore *context = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButCompleteFunc autocomplete_func = nullptr;
|
|
|
|
|
void *autofunc_arg = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButHandleRenameFunc rename_func = nullptr;
|
|
|
|
|
void *rename_arg1 = nullptr;
|
|
|
|
|
void *rename_orig = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/**
|
|
|
|
|
* When defined, and the button edits a string RNA property,
|
|
|
|
|
* the new name is _not_ set at all, instead this function is called with the new name.
|
|
|
|
|
*/
|
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
|
|
|
std::function<void(std::string &new_name)> rename_full_func = nullptr;
|
2025-01-26 20:08:00 +01:00
|
|
|
std::string rename_full_new;
|
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
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
/** Run an action when holding the button down. */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButHandleHoldFunc hold_func = nullptr;
|
|
|
|
|
void *hold_argN = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-02-14 15:12:48 -05:00
|
|
|
blender::StringRef tip;
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButToolTipFunc tip_func = nullptr;
|
|
|
|
|
void *tip_arg = nullptr;
|
|
|
|
|
uiFreeArgFunc tip_arg_free = nullptr;
|
2023-09-21 14:49:53 +02:00
|
|
|
/** Function to override the label to be displayed in the tooltip. */
|
2025-05-09 13:34:35 +02:00
|
|
|
std::function<std::string(const uiBut *)> tip_quick_func;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-09-15 21:06:30 +02:00
|
|
|
uiButToolTipCustomFunc tip_custom_func = nullptr;
|
|
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
/** info on why button is disabled, displayed in tooltip */
|
2023-02-03 16:12:14 +01:00
|
|
|
const char *disabled_info = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
BIFIconID icon = ICON_NONE;
|
2020-12-19 10:07:13 -06:00
|
|
|
/** Copied from the #uiBlock.emboss */
|
2025-03-31 00:36:46 +02:00
|
|
|
blender::ui::EmbossType emboss = blender::ui::EmbossType::Emboss;
|
2022-04-02 16:17:48 -05:00
|
|
|
/** direction in a pie menu, used for collision detection. */
|
2023-02-03 16:12:14 +01:00
|
|
|
RadialDirection pie_dir = UI_RADIAL_NONE;
|
2019-01-15 23:24:20 +11:00
|
|
|
/** could be made into a single flag */
|
2023-02-03 16:12:14 +01:00
|
|
|
bool changed = false;
|
2019-01-15 23:24:20 +11:00
|
|
|
/** so buttons can support unit systems which are not RNA */
|
2023-02-03 16:12:14 +01:00
|
|
|
uchar unit_type = 0;
|
|
|
|
|
short iconadd = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2024-04-16 12:18:45 +02:00
|
|
|
/** Affects the order if this uiBut is used in menu-search. */
|
|
|
|
|
float search_weight = 0.0f;
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #UI_BTYPE_BLOCK data */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiBlockCreateFunc block_create_func = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #UI_BTYPE_PULLDOWN / #UI_BTYPE_MENU data */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiMenuCreateFunc menu_create_func = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiMenuStepFunc menu_step_func = nullptr;
|
2025-01-06 17:30:47 +01:00
|
|
|
/** See #UI_but_menu_disable_hover_open(). */
|
|
|
|
|
bool menu_no_hover_open = false;
|
2019-04-17 06:17:24 +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
|
|
|
/* RNA data */
|
2023-02-03 16:12:14 +01:00
|
|
|
PointerRNA rnapoin = {};
|
|
|
|
|
PropertyRNA *rnaprop = nullptr;
|
2023-06-06 11:30:49 +02:00
|
|
|
int rnaindex = 0;
|
2019-04-17 06:17:24 +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
|
|
|
/* Operator data */
|
2023-02-03 16:12:14 +01:00
|
|
|
wmOperatorType *optype = nullptr;
|
|
|
|
|
PointerRNA *opptr = nullptr;
|
|
|
|
|
wmOperatorCallContext opcontext = WM_OP_INVOKE_DEFAULT;
|
2024-07-12 10:02:10 +02:00
|
|
|
/**
|
|
|
|
|
* Keep an operator attached but never actually call it through the button. See
|
|
|
|
|
* #UI_but_operator_set_never_call().
|
|
|
|
|
*/
|
|
|
|
|
bool operator_never_call = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** When non-zero, this is the key used to activate a menu items (`a-z` always lower case). */
|
2023-02-03 16:12:14 +01:00
|
|
|
uchar menu_key = 0;
|
2021-04-30 16:15:22 +10:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
ListBase extra_op_icons = {nullptr, nullptr}; /** #uiButExtraOpIcon */
|
2019-09-09 16:34:16 +02:00
|
|
|
|
2023-05-17 16:09:34 +02:00
|
|
|
eWM_DragDataType dragtype = WM_DRAG_ID;
|
2023-02-03 16:12:14 +01:00
|
|
|
short dragflag = 0;
|
|
|
|
|
void *dragpoin = nullptr;
|
2025-01-24 22:32:27 +01:00
|
|
|
BIFIconID drag_preview_icon_id;
|
2023-07-13 10:10:44 +10:00
|
|
|
const ImBuf *imb = nullptr;
|
2023-02-03 16:12:14 +01:00
|
|
|
float imb_scale = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-10-25 18:36:27 +02:00
|
|
|
/**
|
|
|
|
|
* Active button data, set when the user is hovering or interacting with a button (#UI_HOVER and
|
|
|
|
|
* #UI_SELECT state mostly).
|
|
|
|
|
*/
|
2023-02-03 16:12:14 +01:00
|
|
|
uiHandleButtonData *active = nullptr;
|
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
|
|
|
/**
|
|
|
|
|
* Event handling only supports one active button at a time, but there are cases where that's not
|
|
|
|
|
* enough. A common one is to keep some filter button active to receive text input, while other
|
|
|
|
|
* buttons remain active for interaction.
|
|
|
|
|
*
|
|
|
|
|
* Buttons that have #semi_modal_state set will be temporarily activated for event handling. If
|
|
|
|
|
* they don't consume the event (for example text input events) the event will be forwarded to
|
|
|
|
|
* other buttons.
|
|
|
|
|
*
|
|
|
|
|
* Currently only text buttons support this well.
|
|
|
|
|
*/
|
|
|
|
|
uiHandleButtonData *semi_modal_state = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Custom button data (borrowed, not owned). */
|
2023-02-03 16:12:14 +01:00
|
|
|
void *custom_data = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
char *editstr = nullptr;
|
|
|
|
|
double *editval = nullptr;
|
|
|
|
|
float *editvec = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-06-05 12:45:33 +02:00
|
|
|
std::function<bool(const uiBut &)> pushed_state_func;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-10-20 16:37:07 +02:00
|
|
|
/** Little indicator (e.g., counter) displayed on top of some icons. */
|
2023-02-03 16:12:14 +01:00
|
|
|
IconTextOverlay icon_overlay_text = {};
|
2022-10-20 16:37:07 +02:00
|
|
|
|
2012-05-08 18:29:02 +00:00
|
|
|
/* pointer back */
|
2023-02-03 16:12:14 +01:00
|
|
|
uiBlock *block = nullptr;
|
|
|
|
|
|
|
|
|
|
uiBut() = default;
|
|
|
|
|
/** Performs a mostly shallow copy for now. Only contained C++ types are deep copied. */
|
|
|
|
|
uiBut(const uiBut &other) = default;
|
|
|
|
|
/** Mostly shallow copy, just like copy constructor above. */
|
|
|
|
|
uiBut &operator=(const uiBut &other) = default;
|
2025-02-14 15:29:26 +01:00
|
|
|
|
|
|
|
|
virtual ~uiBut() = default;
|
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
|
|
|
};
|
|
|
|
|
|
2020-09-04 21:18:45 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_NUM */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButNumber : public uiBut {
|
2024-02-01 12:42:25 -05:00
|
|
|
float step_size = 0.0f;
|
|
|
|
|
float precision = 0.0f;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/** Derived struct for #UI_BTYPE_NUM_SLIDER */
|
|
|
|
|
struct uiButNumberSlider : public uiBut {
|
|
|
|
|
float step_size = 0.0f;
|
|
|
|
|
float precision = 0.0f;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-09-04 21:18:45 +02:00
|
|
|
|
2020-08-07 15:02:07 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_COLOR */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButColor : public uiBut {
|
|
|
|
|
bool is_pallete_color = false;
|
|
|
|
|
int palette_color_index = -1;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-07 15:02:07 +02:00
|
|
|
|
2020-08-07 14:34:11 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_TAB */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButTab : public uiBut {
|
2024-01-24 12:24:12 -05:00
|
|
|
MenuType *menu = nullptr;
|
2022-11-26 00:21:17 -06: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
|
|
|
|
2020-08-07 14:34:11 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_SEARCH_MENU */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButSearch : public uiBut {
|
|
|
|
|
uiButSearchCreateFn popup_create_fn = nullptr;
|
|
|
|
|
uiButSearchUpdateFn items_update_fn = nullptr;
|
|
|
|
|
uiButSearchListenFn listen_fn = nullptr;
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
void *item_active = nullptr;
|
2023-09-25 10:56:12 +02:00
|
|
|
char *item_active_str;
|
2022-09-19 11:57:10 -05:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
void *arg = nullptr;
|
|
|
|
|
uiFreeArgFunc arg_free_fn = nullptr;
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
uiButSearchContextMenuFn item_context_menu_fn = nullptr;
|
|
|
|
|
uiButSearchTooltipFn item_tooltip_fn = nullptr;
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
const char *item_sep_string = nullptr;
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
PointerRNA rnasearchpoin = {};
|
|
|
|
|
PropertyRNA *rnasearchprop = nullptr;
|
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
|
|
|
|
2024-02-29 21:49:22 -05:00
|
|
|
int preview_rows = 0;
|
|
|
|
|
int preview_cols = 0;
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* The search box only provides suggestions, it does not force
|
|
|
|
|
* the string to match one of the search items when applying.
|
|
|
|
|
*/
|
2023-02-03 16:12:14 +01:00
|
|
|
bool results_are_suggestions = false;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-05-27 15:10:58 +10:00
|
|
|
/**
|
|
|
|
|
* Derived struct for #UI_BTYPE_DECORATOR
|
2024-03-07 16:20:36 -05:00
|
|
|
* Decorators have their own RNA data, using the normal #uiBut RNA members has many side-effects.
|
2023-02-03 16:12:14 +01:00
|
|
|
*/
|
|
|
|
|
struct uiButDecorator : public uiBut {
|
2024-08-27 15:35:18 +02:00
|
|
|
PointerRNA decorated_rnapoin = {};
|
|
|
|
|
PropertyRNA *decorated_rnaprop = nullptr;
|
2023-02-03 16:12:14 +01:00
|
|
|
int decorated_rnaindex = -1;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-07 14:34:11 +02:00
|
|
|
|
2023-07-12 13:15:39 +10:00
|
|
|
/** Derived struct for #UI_BTYPE_PROGRESS. */
|
|
|
|
|
struct uiButProgress : public uiBut {
|
|
|
|
|
/** Progress in 0..1 range */
|
|
|
|
|
float progress_factor = 0.0f;
|
2023-07-12 13:18:06 +10:00
|
|
|
/** The display style (bar, pie... etc). */
|
|
|
|
|
eButProgressType progress_type = UI_BUT_PROGRESS_TYPE_BAR;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-07 15:16:26 +02:00
|
|
|
|
2024-03-01 18:09:02 +01:00
|
|
|
/** Derived struct for #UI_BTYPE_SEPR_LINE. */
|
|
|
|
|
struct uiButSeparatorLine : public uiBut {
|
|
|
|
|
bool is_vertical;
|
|
|
|
|
};
|
|
|
|
|
|
2024-03-01 13:46:06 -05:00
|
|
|
/** Derived struct for #UI_BTYPE_LABEL. */
|
|
|
|
|
struct uiButLabel : public uiBut {
|
|
|
|
|
float alpha_factor = 1.0f;
|
|
|
|
|
};
|
|
|
|
|
|
2024-03-01 13:59:03 -05:00
|
|
|
/** Derived struct for #UI_BTYPE_SCROLL. */
|
|
|
|
|
struct uiButScrollBar : public uiBut {
|
|
|
|
|
/** Actual visual height of UI list (in rows). */
|
|
|
|
|
float visual_height = -1.0f;
|
|
|
|
|
};
|
|
|
|
|
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButViewItem : public uiBut {
|
2025-05-13 11:13:48 +10:00
|
|
|
/** The view item this button was created for. */
|
2024-03-08 09:16:00 -05:00
|
|
|
blender::ui::AbstractViewItem *view_item = nullptr;
|
2025-05-13 11:13:48 +10:00
|
|
|
/**
|
|
|
|
|
* Some items want to have a fixed size for drawing, differing from the interaction rectangle
|
|
|
|
|
* (e.g. so highlights are drawn smaller).
|
|
|
|
|
*/
|
2023-09-22 17:15:12 +02:00
|
|
|
int draw_width = 0;
|
|
|
|
|
int draw_height = 0;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2022-06-16 11:29:20 +02:00
|
|
|
|
2020-08-13 21:00:54 -04:00
|
|
|
/** Derived struct for #UI_BTYPE_HSVCUBE. */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButHSVCube : public uiBut {
|
|
|
|
|
eButGradientType gradient_type = UI_GRAD_SV;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-07 17:42:13 +02:00
|
|
|
|
2020-09-04 19:26:12 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_COLORBAND. */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButColorBand : public uiBut {
|
|
|
|
|
ColorBand *edit_coba = nullptr;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-13 22:00:50 -04:00
|
|
|
|
2020-08-13 21:00:54 -04:00
|
|
|
/** Derived struct for #UI_BTYPE_CURVEPROFILE. */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButCurveProfile : public uiBut {
|
2023-08-04 22:47:22 -04:00
|
|
|
CurveProfile *edit_profile = nullptr;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-13 21:00:54 -04:00
|
|
|
|
2020-08-13 21:33:47 -04:00
|
|
|
/** Derived struct for #UI_BTYPE_CURVE. */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButCurveMapping : public uiBut {
|
2023-08-04 22:47:22 -04:00
|
|
|
CurveMapping *edit_cumap = nullptr;
|
2023-02-03 16:12:14 +01:00
|
|
|
eButGradientType gradient_type = UI_GRAD_SV;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2020-08-13 21:33:47 -04:00
|
|
|
|
2022-05-12 17:30:18 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_HOTKEY_EVENT. */
|
2023-02-03 16:12:14 +01:00
|
|
|
struct uiButHotkeyEvent : public uiBut {
|
2025-03-31 23:48:29 +00:00
|
|
|
wmEventModifierFlag modifier_key = wmEventModifierFlag(0);
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2022-05-12 17:30:18 +02:00
|
|
|
|
2019-09-09 16:34:16 +02:00
|
|
|
/**
|
|
|
|
|
* Additional, superimposed icon for a button, invoking an operator.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiButExtraOpIcon {
|
|
|
|
|
uiButExtraOpIcon *next, *prev;
|
2019-09-09 16:34:16 +02:00
|
|
|
|
|
|
|
|
BIFIconID icon;
|
2022-11-26 00:21:17 -06:00
|
|
|
wmOperatorCallParams *optype_params;
|
2020-09-18 20:10:40 +02:00
|
|
|
|
|
|
|
|
bool highlighted;
|
2021-10-08 16:17:29 +02:00
|
|
|
bool disabled;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2019-09-09 16:34:16 +02:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
struct ColorPicker {
|
2023-08-04 22:47:22 -04:00
|
|
|
ColorPicker *next, *prev;
|
2020-12-17 19:29:39 +01:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/**
|
|
|
|
|
* Color in HSV or HSL, in color picking color space. Used for HSV cube,
|
2020-12-17 19:29:39 +01:00
|
|
|
* circle and slider widgets. The color picking space is perceptually
|
2025-05-13 11:13:48 +10:00
|
|
|
* linear for intuitive editing.
|
|
|
|
|
*/
|
2020-12-17 19:39:39 +01:00
|
|
|
float hsv_perceptual[3];
|
2020-12-17 19:29:39 +01:00
|
|
|
/** Initial color data (to detect changes). */
|
2020-12-17 19:39:39 +01:00
|
|
|
float hsv_perceptual_init[3];
|
2019-01-18 12:07:04 +11:00
|
|
|
bool is_init;
|
2020-12-17 19:29:39 +01:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/**
|
|
|
|
|
* HSV or HSL color in scene linear color space value used for number
|
2020-12-17 19:29:39 +01:00
|
|
|
* buttons. This is scene linear so that there is a clear correspondence
|
2025-05-13 11:13:48 +10:00
|
|
|
* to the scene linear RGB values.
|
|
|
|
|
*/
|
2020-12-17 19:39:39 +01:00
|
|
|
float hsv_scene_linear[3];
|
2020-12-17 19:29:39 +01:00
|
|
|
|
2019-03-22 14:01:11 +11:00
|
|
|
/** Cubic saturation for the color wheel. */
|
|
|
|
|
bool use_color_cubic;
|
|
|
|
|
bool use_color_lock;
|
|
|
|
|
bool use_luminosity_lock;
|
|
|
|
|
float luminosity_lock_value;
|
2024-09-25 18:56:32 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/** Alpha component. */
|
2024-09-25 18:56:32 +02:00
|
|
|
bool has_alpha;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2014-11-06 20:19:21 +01:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
struct ColorPickerData {
|
2014-11-06 20:19:21 +01:00
|
|
|
ListBase list;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2014-11-06 20:19:21 +01: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
|
|
|
struct PieMenuData {
|
2019-01-15 23:24:20 +11:00
|
|
|
/** store title and icon to allow access when pie levels are created */
|
2016-02-16 14:50:26 +01:00
|
|
|
const char *title;
|
|
|
|
|
int icon;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-09-14 16:10:36 +10:00
|
|
|
/** A mask combining the directions of all buttons in the pie menu (excluding separators). */
|
|
|
|
|
int pie_dir_mask;
|
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
|
|
|
float pie_dir[2];
|
|
|
|
|
float pie_center_init[2];
|
|
|
|
|
float pie_center_spawned[2];
|
2014-10-10 19:13:40 +02:00
|
|
|
float last_pos[2];
|
|
|
|
|
double duration_gesture;
|
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
|
|
|
int flags;
|
2021-03-05 14:42:48 +11:00
|
|
|
/** Initial event used to fire the pie menu, store here so we can query for release */
|
|
|
|
|
short event_type;
|
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
|
|
|
float alphafac;
|
|
|
|
|
};
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #uiBlock.content_hints */
|
2018-07-06 19:26:12 +02:00
|
|
|
enum eBlockContentHints {
|
2019-01-15 23:24:20 +11:00
|
|
|
/** In a menu block, if there is a single sub-menu button, we add some
|
2018-07-06 19:26:12 +02:00
|
|
|
* padding to the right to put nicely aligned triangle icons there. */
|
2018-09-11 15:08:08 +10:00
|
|
|
UI_BLOCK_CONTAINS_SUBMENU_BUT = (1 << 0),
|
2018-07-06 19:26:12 +02:00
|
|
|
};
|
|
|
|
|
|
2020-10-03 11:25:13 -05:00
|
|
|
/* #uiButtonGroup.flag. */
|
2022-11-26 00:21:17 -06:00
|
|
|
enum uiButtonGroupFlag {
|
2020-10-03 11:25:13 -05:00
|
|
|
/** While this flag is set, don't create new button groups for layout item calls. */
|
|
|
|
|
UI_BUTTON_GROUP_LOCK = (1 << 0),
|
|
|
|
|
/** The buttons in this group are inside a panel header. */
|
|
|
|
|
UI_BUTTON_GROUP_PANEL_HEADER = (1 << 1),
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2022-07-29 23:16:58 -05:00
|
|
|
ENUM_OPERATORS(uiButtonGroupFlag, UI_BUTTON_GROUP_PANEL_HEADER);
|
2020-10-03 11:25:13 -05:00
|
|
|
|
2022-12-18 21:45:32 -06:00
|
|
|
/**
|
|
|
|
|
* A group of button references, used by property search to keep track of sets of buttons that
|
|
|
|
|
* should be searched together. For example, in property split layouts number buttons and their
|
|
|
|
|
* labels (and even their decorators) are separate buttons, but they must be searched and
|
|
|
|
|
* highlighted together.
|
|
|
|
|
*/
|
|
|
|
|
struct uiButtonGroup {
|
|
|
|
|
blender::Vector<uiBut *> buttons;
|
|
|
|
|
uiButtonGroupFlag flag;
|
|
|
|
|
};
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiBlockDynamicListener {
|
2023-08-03 01:11:28 +02:00
|
|
|
uiBlockDynamicListener *next, *prev;
|
2022-11-01 17:36:36 +01:00
|
|
|
|
2023-08-03 01:11:28 +02:00
|
|
|
void (*listener_func)(const wmRegionListenerParams *params);
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2022-11-01 17:36:36 +01: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
|
|
|
struct uiBlock {
|
|
|
|
|
uiBlock *next, *prev;
|
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
|
|
|
|
2025-02-14 15:29:26 +01:00
|
|
|
blender::Vector<std::unique_ptr<uiBut>> buttons;
|
2022-11-26 00:21:17 -06:00
|
|
|
Panel *panel;
|
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
|
|
|
uiBlock *oldblock;
|
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
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Used for `UI_butstore_*` runtime function. */
|
|
|
|
|
ListBase butstore;
|
2014-02-08 09:03:25 +11:00
|
|
|
|
2022-12-18 21:45:32 -06:00
|
|
|
blender::Vector<uiButtonGroup> button_groups;
|
2020-10-02 17:00:41 -05:00
|
|
|
|
2009-05-19 17:13:33 +00:00
|
|
|
ListBase layouts;
|
2022-11-26 00:21:17 -06:00
|
|
|
uiLayout *curlayout;
|
2009-05-28 23:13:42 +00:00
|
|
|
|
2023-08-31 10:46:53 -04:00
|
|
|
blender::Vector<std::unique_ptr<bContextStore>> contexts;
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2021-09-23 18:56:29 +02:00
|
|
|
/** A block can store "views" on data-sets. Currently tree-views (#AbstractTreeView) only.
|
|
|
|
|
* Others are imaginable, e.g. table-views, grid-views, etc. These are stored here to support
|
|
|
|
|
* state that is persistent over redraws (e.g. collapsed tree-view items). */
|
|
|
|
|
ListBase views;
|
|
|
|
|
|
2022-11-01 17:36:36 +01:00
|
|
|
ListBase dynamic_listeners; /* #uiBlockDynamicListener */
|
|
|
|
|
|
2024-01-18 15:59:20 -05:00
|
|
|
std::string name;
|
2018-05-23 10:47:12 +02: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
|
|
|
float winmat[4][4];
|
2012-08-18 16:53:46 +00:00
|
|
|
|
|
|
|
|
rctf rect;
|
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
|
|
|
float aspect;
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Unique hash used to implement popup menu memory. */
|
|
|
|
|
uint puphash;
|
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
|
|
|
|
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
|
|
|
uiButHandleFunc 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
|
|
|
void *func_arg1;
|
|
|
|
|
void *func_arg2;
|
2008-12-10 19:22:10 +00:00
|
|
|
|
2009-09-16 18:47:42 +00:00
|
|
|
uiButHandleNFunc funcN;
|
|
|
|
|
void *func_argN;
|
2024-07-05 17:09:40 +02:00
|
|
|
uiButArgNFree func_argN_free_fn;
|
|
|
|
|
uiButArgNCopy func_argN_copy_fn;
|
2009-09-16 18:47:42 +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
|
|
|
uiBlockHandleFunc handle_func;
|
2008-12-10 19:22:10 +00:00
|
|
|
void *handle_func_arg;
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2021-07-08 16:23:41 +10:00
|
|
|
/** Custom interaction data. */
|
|
|
|
|
uiBlockInteraction_CallbackData custom_interaction_callbacks;
|
|
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Custom extra event handling. */
|
2022-11-26 00:21:17 -06:00
|
|
|
int (*block_event_func)(const bContext *C, uiBlock *, const wmEvent *);
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Custom extra draw function for custom blocks. */
|
2024-11-01 15:25:24 +01:00
|
|
|
std::function<void(const bContext *, rcti *)> drawextra;
|
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
|
|
|
|
2010-10-07 00:14:21 +00:00
|
|
|
int flag;
|
2011-10-03 01:36:25 +00:00
|
|
|
short alignnr;
|
2019-01-15 23:24:20 +11:00
|
|
|
/** Hints about the buttons of this block. Used to avoid iterating over
|
2018-07-06 19:26:12 +02:00
|
|
|
* buttons to find out if some criteria is met by any. Instead, check this
|
|
|
|
|
* criteria when adding the button and set a flag here if it's met. */
|
2021-04-30 16:15:22 +10:00
|
|
|
short content_hints; /* #eBlockContentHints */
|
2011-10-03 01:36:25 +00:00
|
|
|
|
2011-08-14 11:38:17 +00:00
|
|
|
char direction;
|
2019-01-15 23:24:20 +11:00
|
|
|
/** UI_BLOCK_THEME_STYLE_* */
|
|
|
|
|
char theme_style;
|
2020-12-19 10:07:13 -06:00
|
|
|
/** Copied to #uiBut.emboss */
|
2025-03-31 00:36:46 +02:00
|
|
|
blender::ui::EmbossType emboss;
|
2014-01-04 17:16:19 +11:00
|
|
|
bool auto_open;
|
2018-07-06 19:26:12 +02:00
|
|
|
char _pad[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
|
|
|
double auto_open_last;
|
|
|
|
|
|
2010-12-03 17:05:21 +00:00
|
|
|
const char *lockstr;
|
2010-10-14 11:33:51 +00:00
|
|
|
|
2021-02-22 13:18:49 -06:00
|
|
|
bool lock;
|
2021-04-30 16:15:22 +10:00
|
|
|
/** To keep blocks while drawing and free them afterwards. */
|
2021-02-22 13:18:49 -06:00
|
|
|
bool active;
|
2021-04-30 16:15:22 +10:00
|
|
|
/** To avoid tool-tip after click. */
|
2021-02-22 13:18:49 -06:00
|
|
|
bool tooltipdisabled;
|
2021-04-30 16:15:22 +10:00
|
|
|
/** True when #UI_block_end has been called. */
|
2021-02-22 13:18:49 -06:00
|
|
|
bool endblock;
|
2019-01-15 23:24:20 +11:00
|
|
|
|
|
|
|
|
/** for doing delayed */
|
|
|
|
|
eBlockBoundsCalc bounds_type;
|
2019-03-13 16:35:24 +11:00
|
|
|
/** Offset to use when calculating bounds (in pixels). */
|
|
|
|
|
int bounds_offset[2];
|
2019-01-15 23:24:20 +11:00
|
|
|
/** for doing delayed */
|
|
|
|
|
int bounds, minbounds;
|
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-04-30 16:15:22 +10:00
|
|
|
/** Pull-downs, to detect outside, can differ per case how it is created. */
|
2019-01-15 23:24:20 +11:00
|
|
|
rctf safety;
|
2021-04-30 16:15:22 +10:00
|
|
|
/** #uiSafetyRct list */
|
2019-01-15 23:24:20 +11:00
|
|
|
ListBase saferct;
|
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-04-30 16:15:22 +10:00
|
|
|
uiPopupBlockHandle *handle;
|
2011-11-10 03:44:50 +00:00
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
/** use so presets can find the operator,
|
|
|
|
|
* across menus and from nested popups which fail for operator context. */
|
2022-11-26 00:21:17 -06:00
|
|
|
wmOperator *ui_operator;
|
2024-03-28 20:40:59 +01:00
|
|
|
bool ui_operator_free;
|
2011-11-10 03:44:50 +00:00
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
/** XXX hack for dynamic operator enums */
|
|
|
|
|
void *evil_C;
|
2010-10-14 11:33:51 +00:00
|
|
|
|
2019-01-15 23:24:20 +11:00
|
|
|
/** unit system, used a lot for numeric buttons so include here
|
|
|
|
|
* rather than fetching through the scene every time. */
|
2024-03-29 16:37:36 +11:00
|
|
|
const UnitSettings *unit;
|
2019-01-15 23:24:20 +11:00
|
|
|
/** \note only accessed by color picker templates. */
|
|
|
|
|
ColorPickerData color_pickers;
|
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
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Block for color picker with gamma baked in. */
|
|
|
|
|
bool is_color_gamma_picker;
|
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
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/**
|
|
|
|
|
* Display device name used to display this block,
|
|
|
|
|
* used by color widgets to transform colors from/to scene linear.
|
2019-01-15 23:24:20 +11:00
|
|
|
*/
|
|
|
|
|
char display_device[64];
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
PieMenuData pie_data;
|
2025-02-14 15:29:26 +01:00
|
|
|
|
|
|
|
|
void remove_but(const uiBut *but);
|
|
|
|
|
[[nodiscard]] uiBut *first_but() const;
|
|
|
|
|
[[nodiscard]] uiBut *last_but() const;
|
|
|
|
|
int but_index(const uiBut *but) const;
|
|
|
|
|
[[nodiscard]] uiBut *next_but(const uiBut *but) const;
|
|
|
|
|
[[nodiscard]] uiBut *prev_but(const uiBut *but) const;
|
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
|
|
|
};
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiSafetyRct {
|
|
|
|
|
uiSafetyRct *next, *prev;
|
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
|
|
|
rctf parent;
|
|
|
|
|
rctf safety;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface.cc` */
|
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-11-13 09:39:18 -08:00
|
|
|
void ui_fontscale(float *points, float aspect);
|
2009-04-15 14:43:54 +00:00
|
|
|
|
2023-07-06 17:00:44 +02:00
|
|
|
/** Project button or block (but==nullptr) to pixels in region-space. */
|
|
|
|
|
void ui_but_to_pixelrect(rcti *rect,
|
|
|
|
|
const ARegion *region,
|
|
|
|
|
const uiBlock *block,
|
|
|
|
|
const uiBut *but);
|
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
|
|
|
rcti ui_to_pixelrect(const ARegion *region, const uiBlock *block, const rctf *src_rect);
|
2023-07-06 17:00:44 +02:00
|
|
|
|
2024-05-06 11:57:59 +10:00
|
|
|
void ui_block_to_region_fl(const ARegion *region, const uiBlock *block, float *x, float *y);
|
2023-06-22 20:30:12 +02:00
|
|
|
void ui_block_to_window_fl(const ARegion *region, const uiBlock *block, float *x, float *y);
|
|
|
|
|
void ui_block_to_window(const ARegion *region, const uiBlock *block, int *x, int *y);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_block_to_region_rctf(const ARegion *region,
|
2023-06-22 20:30:12 +02:00
|
|
|
const uiBlock *block,
|
2022-11-26 00:21:17 -06:00
|
|
|
rctf *rct_dst,
|
|
|
|
|
const rctf *rct_src);
|
|
|
|
|
void ui_block_to_window_rctf(const ARegion *region,
|
2023-06-22 20:30:12 +02:00
|
|
|
const uiBlock *block,
|
2022-11-26 00:21:17 -06:00
|
|
|
rctf *rct_dst,
|
|
|
|
|
const rctf *rct_src);
|
2023-06-22 20:30:12 +02:00
|
|
|
float ui_block_to_window_scale(const ARegion *region, const uiBlock *block);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For mouse cursor.
|
|
|
|
|
*/
|
2023-06-22 20:30:12 +02:00
|
|
|
void ui_window_to_block_fl(const ARegion *region, const uiBlock *block, float *x, float *y);
|
|
|
|
|
void ui_window_to_block(const ARegion *region, const uiBlock *block, int *x, int *y);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_window_to_block_rctf(const ARegion *region,
|
2023-06-22 20:30:12 +02:00
|
|
|
const uiBlock *block,
|
2022-11-26 00:21:17 -06:00
|
|
|
rctf *rct_dst,
|
|
|
|
|
const rctf *rct_src);
|
|
|
|
|
void ui_window_to_region(const ARegion *region, int *x, int *y);
|
|
|
|
|
void ui_window_to_region_rcti(const ARegion *region, rcti *rect_dst, const rcti *rct_src);
|
|
|
|
|
void ui_window_to_region_rctf(const ARegion *region, rctf *rect_dst, const rctf *rct_src);
|
|
|
|
|
void ui_region_to_window(const ARegion *region, int *x, int *y);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Popups will add a margin to #ARegion.winrct for shadow,
|
|
|
|
|
* for interactivity (point-inside tests for eg), we want the winrct without the margin added.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_region_winrct_get_no_margin(const ARegion *region, rcti *r_rect);
|
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 18:37:28 +02:00
|
|
|
/** Register a listener callback to this block to tag the area/region for redraw. */
|
|
|
|
|
void ui_block_add_dynamic_listener(uiBlock *block,
|
|
|
|
|
void (*listener_func)(const wmRegionListenerParams *params));
|
|
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Reallocate the button (new address is returned) for a new button type.
|
|
|
|
|
* This should generally be avoided and instead the correct type be created right away.
|
|
|
|
|
*
|
|
|
|
|
* \note Only the #uiBut data can be kept. If the old button used a derived type (e.g. #uiButTab),
|
|
|
|
|
* the data that is not inside #uiBut will be lost.
|
|
|
|
|
*/
|
2020-08-07 14:34:11 +02:00
|
|
|
uiBut *ui_but_change_type(uiBut *but, eButType new_type);
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
double ui_but_value_get(uiBut *but);
|
|
|
|
|
void ui_but_value_set(uiBut *but, double value);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For picker, while editing HSV.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_hsv_set(uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* For buttons pointing to color for example.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_v3_get(uiBut *but, float vec[3]);
|
|
|
|
|
void ui_but_v3_set(uiBut *but, const float vec[3]);
|
2024-09-25 18:56:32 +02:00
|
|
|
void ui_but_v4_get(uiBut *but, float vec[4]);
|
|
|
|
|
void ui_but_v4_set(uiBut *but, const float vec[4]);
|
2009-03-30 17:31:37 +00:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_hsvcircle_vals_from_pos(
|
2022-01-07 11:38:08 +11:00
|
|
|
const rcti *rect, float mx, float my, float *r_val_rad, float *r_val_dist);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Cursor in HSV circle, in float units -1 to 1, to map on radius.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_hsvcircle_pos_from_vals(
|
2024-07-27 13:20:43 +10:00
|
|
|
const ColorPicker *cpicker, const rcti *rect, const float *hsv, float *r_xpos, float *r_ypos);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_hsvcube_pos_from_vals(
|
2024-07-27 13:20:43 +10:00
|
|
|
const uiButHSVCube *hsv_but, const rcti *rect, const float *hsv, float *r_xp, float *r_yp);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \param float_precision: For number buttons the precision
|
|
|
|
|
* to use or -1 to fallback to the button default.
|
|
|
|
|
* \param use_exp_float: Use exponent representation of floats
|
|
|
|
|
* when out of reasonable range (outside of 1e3/1e-3).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_string_get_ex(uiBut *but,
|
|
|
|
|
char *str,
|
2023-05-07 15:22:58 +10:00
|
|
|
size_t str_maxncpy,
|
2022-11-26 00:21:17 -06:00
|
|
|
int float_precision,
|
|
|
|
|
bool use_exp_float,
|
|
|
|
|
bool *r_use_exp_float) ATTR_NONNULL(1, 2);
|
2023-05-07 15:22:58 +10:00
|
|
|
void ui_but_string_get(uiBut *but, char *str, size_t str_maxncpy) ATTR_NONNULL();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* A version of #ui_but_string_get_ex for dynamic buffer sizes
|
2023-06-10 17:21:24 +10:00
|
|
|
* (where #ui_but_string_get_maxncpy returns 0).
|
2021-12-09 00:55:11 +11:00
|
|
|
*
|
|
|
|
|
* \param r_str_size: size of the returned string (including terminator).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
char *ui_but_string_get_dynamic(uiBut *but, int *r_str_size);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \param str: will be overwritten.
|
|
|
|
|
*/
|
2023-05-07 15:22:58 +10:00
|
|
|
void ui_but_convert_to_unit_alt_name(uiBut *but, char *str, size_t str_maxncpy) ATTR_NONNULL();
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_but_string_set(bContext *C, uiBut *but, const char *str) ATTR_NONNULL();
|
2024-07-27 13:20:43 +10:00
|
|
|
bool ui_but_string_eval_number(bContext *C, const uiBut *but, const char *str, double *r_value)
|
2022-11-26 00:21:17 -06:00
|
|
|
ATTR_NONNULL();
|
2023-06-10 17:21:24 +10:00
|
|
|
int ui_but_string_get_maxncpy(uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Clear & exit the active button's string..
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_active_string_clear_and_exit(bContext *C, uiBut *but) ATTR_NONNULL();
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Use handling code to set a string for the button. Handles the case where the string is set for a
|
|
|
|
|
* search button while the search menu is open, so the results are updated accordingly.
|
|
|
|
|
* This is basically the same as pasting the string into the button.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_set_string_interactive(bContext *C, uiBut *but, const char *value);
|
|
|
|
|
uiBut *ui_but_drag_multi_edit_get(uiBut *but);
|
2015-05-11 16:29:12 +02:00
|
|
|
|
2023-10-12 11:44:08 -07:00
|
|
|
/**
|
|
|
|
|
* Get the hint that describes the expected value when empty.
|
|
|
|
|
*/
|
|
|
|
|
const char *ui_but_placeholder_get(uiBut *but);
|
|
|
|
|
|
2022-05-12 15:53:12 +02:00
|
|
|
void ui_def_but_icon(uiBut *but, int icon, int flag);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Avoid using this where possible since it's better not to ask for an icon in the first place.
|
|
|
|
|
*/
|
2019-05-21 14:39:09 +10:00
|
|
|
void ui_def_but_icon_clear(uiBut *but);
|
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-09-09 16:34:16 +02:00
|
|
|
void ui_but_extra_operator_icons_free(uiBut *but);
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_rna_menu_convert_to_panel_type(uiBut *but, const char *panel_type);
|
|
|
|
|
void ui_but_rna_menu_convert_to_menu_type(uiBut *but, const char *menu_type);
|
|
|
|
|
bool ui_but_menu_draw_as_popover(const uiBut *but);
|
2019-03-25 18:55:38 +11:00
|
|
|
|
2020-07-09 15:38:31 +02:00
|
|
|
void ui_but_range_set_hard(uiBut *but);
|
|
|
|
|
void ui_but_range_set_soft(uiBut *but);
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_but_context_poll_operator(bContext *C, wmOperatorType *ot, const uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the operator \a ot poll is successful with the context given by \a but (optionally).
|
|
|
|
|
* \param but: The button that might store context. Can be NULL for convenience (e.g. if there is
|
|
|
|
|
* no button to take context from, but we still want to poll the operator).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_but_context_poll_operator_ex(bContext *C,
|
2021-10-08 16:17:29 +02:00
|
|
|
const uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const wmOperatorCallParams *optype_params);
|
|
|
|
|
|
|
|
|
|
void ui_but_update(uiBut *but);
|
|
|
|
|
void ui_but_update_edited(uiBut *but);
|
|
|
|
|
PropertyScaleType ui_but_scale_type(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_float(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_bool(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_unit(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if this button is similar enough to be grouped with another.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_but_is_compatible(const uiBut *but_a, const uiBut *but_b) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_rna_valid(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Checks if the button supports cycling next/previous menu items (ctrl+mouse-wheel).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_but_supports_cycling(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
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-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the button is pushed, this is only meaningful for some button types.
|
|
|
|
|
*
|
|
|
|
|
* \return (0 == UNSELECT), (1 == SELECT), (-1 == DO-NOTHING)
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
int ui_but_is_pushed_ex(uiBut *but, double *value) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
int ui_but_is_pushed(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2013-03-01 00:19:32 +00:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_override_flag(Main *bmain, uiBut *but);
|
2013-03-01 00:19:32 +00:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_block_bounds_calc(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
|
|
|
|
Refactor: OpenColorIO integration
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
2025-05-09 14:01:43 +02:00
|
|
|
const ColorManagedDisplay *ui_block_cm_display_get(uiBlock *block);
|
2014-11-09 21:20:40 +01:00
|
|
|
void ui_block_cm_to_display_space_v3(uiBlock *block, float pixel[3]);
|
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-07-31 11:50:54 +10:00
|
|
|
/* `interface_regions.cc` */
|
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-04-11 02:28:34 +00:00
|
|
|
struct uiKeyNavLock {
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Set when we're using keyboard-input. */
|
2025-02-11 12:40:47 -05:00
|
|
|
bool is_keynav = false;
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Only used to check if we've moved the cursor. */
|
2025-02-11 12:40:47 -05:00
|
|
|
blender::int2 event_xy = blender::int2(0);
|
2013-04-11 02:28:34 +00:00
|
|
|
};
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
using uiBlockHandleCreateFunc = uiBlock *(*)(bContext *C, uiPopupBlockHandle *handle, void *arg1);
|
2014-06-15 01:40:15 +10:00
|
|
|
|
|
|
|
|
struct uiPopupBlockCreate {
|
2025-02-11 12:40:47 -05:00
|
|
|
uiBlockCreateFunc create_func = nullptr;
|
|
|
|
|
uiBlockHandleCreateFunc handle_create_func = nullptr;
|
|
|
|
|
void *arg = nullptr;
|
|
|
|
|
uiFreeArgFunc arg_free = nullptr;
|
2014-06-15 01:40:15 +10:00
|
|
|
|
2025-02-11 12:40:47 -05:00
|
|
|
blender::int2 event_xy = blender::int2(0);
|
2014-06-15 01:40:15 +10:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Set when popup is initialized from a button. */
|
2025-02-11 12:40:47 -05:00
|
|
|
ARegion *butregion = nullptr;
|
|
|
|
|
uiBut *but = nullptr;
|
2014-06-15 01:40:15 +10: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
|
|
|
struct uiPopupBlockHandle {
|
|
|
|
|
/* internal */
|
2025-02-11 12:40:47 -05:00
|
|
|
ARegion *region = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Use only for #UI_BLOCK_MOVEMOUSE_QUIT popups. */
|
2013-06-13 09:12:53 +00:00
|
|
|
float towards_xy[2];
|
2025-02-11 12:40:47 -05:00
|
|
|
double towardstime = 0.0;
|
|
|
|
|
bool dotowards = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-02-11 12:40:47 -05:00
|
|
|
bool popup = false;
|
|
|
|
|
void (*popup_func)(bContext *C, void *arg, int event) = nullptr;
|
|
|
|
|
void (*cancel_func)(bContext *C, void *arg) = nullptr;
|
|
|
|
|
void *popup_arg = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Store data for refreshing popups. */
|
2022-11-26 00:21:17 -06:00
|
|
|
uiPopupBlockCreate popup_create_vars;
|
2024-05-14 14:08:28 +10:00
|
|
|
/**
|
|
|
|
|
* True if we can re-create the popup using #uiPopupBlockHandle.popup_create_vars.
|
|
|
|
|
*
|
|
|
|
|
* \note Popups that can refresh are called with #bContext::wm::region_popup set
|
|
|
|
|
* to the #uiPopupBlockHandle::region both on initial creation and when refreshing.
|
|
|
|
|
*/
|
2025-02-11 12:40:47 -05:00
|
|
|
bool can_refresh = false;
|
|
|
|
|
bool refresh = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-02-11 12:40:47 -05:00
|
|
|
wmTimer *scrolltimer = nullptr;
|
|
|
|
|
float scrolloffset = 0.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiKeyNavLock keynav_state;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-02-04 11:52:16 +00:00
|
|
|
/* for operator popups */
|
2025-02-11 12:40:47 -05:00
|
|
|
wmOperator *popup_op = nullptr;
|
|
|
|
|
ScrArea *ctx_area = nullptr;
|
|
|
|
|
ARegion *ctx_region = nullptr;
|
2019-04-17 06:17:24 +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
|
|
|
/* return values */
|
2025-02-11 12:40:47 -05:00
|
|
|
int butretval = 0;
|
|
|
|
|
int menuretval = 0;
|
|
|
|
|
int retvalue = 0;
|
|
|
|
|
float retvec[4] = {0.0f, 0.0f, 0.0f, 0.0f};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-04-30 16:15:22 +10:00
|
|
|
/** Menu direction. */
|
2025-02-11 12:40:47 -05:00
|
|
|
int direction = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-06 18:08:27 +02:00
|
|
|
/* Previous values so we don't resize or reposition on refresh. */
|
2025-02-11 12:40:47 -05:00
|
|
|
rctf prev_block_rect = {};
|
|
|
|
|
rctf prev_butrct = {};
|
|
|
|
|
short prev_dir1 = 0;
|
|
|
|
|
short prev_dir2 = 0;
|
|
|
|
|
int prev_bounds_offset[2] = {0, 0};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-06 18:08:27 +02:00
|
|
|
/* Maximum estimated size to avoid having to reposition on refresh. */
|
2025-02-11 12:40:47 -05:00
|
|
|
float max_size_x = 0.0f;
|
|
|
|
|
float max_size_y = 0.0f;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-04-02 18:42:08 +11:00
|
|
|
/* #ifdef USE_DRAG_POPUP */
|
2025-02-11 12:40:47 -05:00
|
|
|
bool is_grab = false;
|
|
|
|
|
int grab_xy_prev[2] = {0, 0};
|
2014-04-02 18:42:08 +11:00
|
|
|
/* #endif */
|
2023-09-06 18:16:45 +02:00
|
|
|
|
2025-02-11 12:40:47 -05:00
|
|
|
char menu_idname[64] = "";
|
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
|
|
|
};
|
|
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* -------------------------------------------------------------------- */
|
2025-05-13 11:13:48 +10:00
|
|
|
/** \name Interface Region Functions
|
|
|
|
|
*
|
|
|
|
|
* `interface_region_*.cc` sources.
|
|
|
|
|
* \{ */
|
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-31 11:50:54 +10:00
|
|
|
/* `interface_region_tooltip.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2023-08-05 02:57:52 +02:00
|
|
|
/* exposed as public API in UI_interface.hh */
|
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-31 11:50:54 +10:00
|
|
|
/* `interface_region_color_picker.cc` */
|
2022-04-04 13:17:03 +10:00
|
|
|
|
2020-12-17 19:39:39 +01:00
|
|
|
void ui_color_picker_rgb_to_hsv_compat(const float rgb[3], float r_cp[3]);
|
|
|
|
|
void ui_color_picker_rgb_to_hsv(const float rgb[3], float r_cp[3]);
|
|
|
|
|
void ui_color_picker_hsv_to_rgb(const float r_cp[3], float rgb[3]);
|
2010-10-13 13:53:49 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Returns true if the button is for a color with gamma baked in,
|
|
|
|
|
* or if it's a color picker for such a button.
|
|
|
|
|
*/
|
2018-12-13 15:59:58 +01:00
|
|
|
bool ui_but_is_color_gamma(uiBut *but);
|
|
|
|
|
|
2024-09-25 18:56:32 +02:00
|
|
|
/**
|
|
|
|
|
* Returns true if the button represents a color with an Alpha component.
|
|
|
|
|
*/
|
|
|
|
|
bool ui_but_color_has_alpha(uiBut *but);
|
|
|
|
|
|
2020-12-17 19:39:39 +01:00
|
|
|
void ui_scene_linear_to_perceptual_space(uiBut *but, float rgb[3]);
|
|
|
|
|
void ui_perceptual_to_scene_linear_space(uiBut *but, float rgb[3]);
|
2018-12-13 15:59:58 +01:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBlock *ui_block_func_COLOR(bContext *C, uiPopupBlockHandle *handle, void *arg_but);
|
|
|
|
|
ColorPicker *ui_block_colorpicker_create(uiBlock *block);
|
2017-11-03 20:26:35 +11:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_search.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Search-box for string button.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
ARegion *ui_searchbox_create_generic(bContext *C, ARegion *butregion, uiButSearch *search_but);
|
|
|
|
|
ARegion *ui_searchbox_create_operator(bContext *C, ARegion *butregion, uiButSearch *search_but);
|
|
|
|
|
ARegion *ui_searchbox_create_menu(bContext *C, ARegion *butregion, uiButSearch *search_but);
|
2020-03-24 11:34:18 +11:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* x and y in screen-coords.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_searchbox_inside(ARegion *region, const int xy[2]) ATTR_NONNULL(1, 2);
|
|
|
|
|
int ui_searchbox_find_index(ARegion *region, const char *name);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Region is the search box itself.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_searchbox_update(bContext *C, ARegion *region, uiBut *but, bool reset);
|
|
|
|
|
int ui_searchbox_autocomplete(bContext *C, ARegion *region, uiBut *but, char *str);
|
|
|
|
|
bool ui_searchbox_event(
|
|
|
|
|
bContext *C, ARegion *region, uiBut *but, ARegion *butregion, const wmEvent *event);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* String validated to be of correct length (but->hardmax).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_searchbox_apply(uiBut *but, ARegion *region);
|
|
|
|
|
void ui_searchbox_free(bContext *C, ARegion *region);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* XXX weak: search_func adds all partial matches.
|
|
|
|
|
*/
|
2020-08-07 14:34:11 +02:00
|
|
|
void ui_but_search_refresh(uiButSearch *but);
|
2009-06-02 18:10:06 +00:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_menu_popup.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
int ui_but_menu_step(uiBut *but, int direction);
|
2017-11-03 20:26:35 +11:00
|
|
|
bool ui_but_menu_step_poll(const uiBut *but);
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_popup_menu_memory_get(uiBlock *block);
|
|
|
|
|
void ui_popup_menu_memory_set(uiBlock *block, uiBut *but);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Called for creating new popups and refreshing existing ones.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBlock *ui_popup_block_refresh(bContext *C,
|
2015-05-05 03:13:47 +10:00
|
|
|
uiPopupBlockHandle *handle,
|
2022-11-26 00:21:17 -06:00
|
|
|
ARegion *butregion,
|
2015-05-05 03:13:47 +10:00
|
|
|
uiBut *but);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiPopupBlockHandle *ui_popup_block_create(bContext *C,
|
|
|
|
|
ARegion *butregion,
|
2015-05-05 03:13:47 +10:00
|
|
|
uiBut *but,
|
|
|
|
|
uiBlockCreateFunc create_func,
|
|
|
|
|
uiBlockHandleCreateFunc handle_create_func,
|
2019-05-14 15:38:51 +02:00
|
|
|
void *arg,
|
2024-05-14 14:08:28 +10:00
|
|
|
uiFreeArgFunc arg_free,
|
|
|
|
|
bool can_refresh);
|
2022-11-26 00:21:17 -06:00
|
|
|
uiPopupBlockHandle *ui_popup_menu_create(
|
|
|
|
|
bContext *C, ARegion *butregion, uiBut *but, uiMenuCreateFunc menu_func, void *arg);
|
2009-08-21 02:51:56 +00:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_popover.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2024-07-07 20:00:35 +02:00
|
|
|
using uiPopoverCreateFunc = std::function<void(bContext *, uiLayout *, PanelType *)>;
|
|
|
|
|
|
2024-01-18 13:54:10 -05:00
|
|
|
uiPopupBlockHandle *ui_popover_panel_create(bContext *C,
|
|
|
|
|
ARegion *butregion,
|
|
|
|
|
uiBut *but,
|
2024-07-07 20:00:35 +02:00
|
|
|
uiPopoverCreateFunc popover_func,
|
2024-01-18 13:54:10 -05:00
|
|
|
const PanelType *panel_type);
|
2018-04-22 17:16:39 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_menu_pie.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set up data for defining a new pie menu level and add button that invokes it.
|
|
|
|
|
*/
|
2016-02-16 14:50:26 +01:00
|
|
|
void ui_pie_menu_level_create(uiBlock *block,
|
2022-11-26 00:21:17 -06:00
|
|
|
wmOperatorType *ot,
|
2025-02-14 14:32:57 -05:00
|
|
|
blender::StringRefNull propname,
|
2022-11-26 00:21:17 -06:00
|
|
|
IDProperty *properties,
|
2016-02-16 14:50:26 +01:00
|
|
|
const EnumPropertyItem *items,
|
|
|
|
|
int totitem,
|
2021-11-05 14:56:22 +01:00
|
|
|
wmOperatorCallContext context,
|
2023-07-29 15:06:33 +10:00
|
|
|
eUI_Item_Flag flag);
|
2016-02-16 14:50:26 +01:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_region_popup.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Translate any popup regions (so we can drag them).
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_popup_translate(ARegion *region, const int mdiff[2]);
|
|
|
|
|
void ui_popup_block_free(bContext *C, uiPopupBlockHandle *handle);
|
|
|
|
|
void ui_popup_block_scrolltest(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
|
|
|
|
2025-05-13 11:13:48 +10: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-31 11:50:54 +10:00
|
|
|
/* `interface_panel.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Handle region panel events like opening and closing panels, changing categories, etc.
|
|
|
|
|
*
|
|
|
|
|
* \note Could become a modal key-map.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
int ui_handler_panel_region(bContext *C,
|
|
|
|
|
const wmEvent *event,
|
|
|
|
|
ARegion *region,
|
|
|
|
|
const uiBut *active_but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draw a panel integrated in buttons-window, tool/property lists etc.
|
|
|
|
|
*/
|
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
|
|
|
void ui_draw_aligned_panel(const ARegion *region,
|
|
|
|
|
const uiStyle *style,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiBlock *block,
|
|
|
|
|
const rcti *rect,
|
|
|
|
|
bool show_pin,
|
|
|
|
|
bool show_background,
|
|
|
|
|
bool region_search_filter_active);
|
2024-05-24 20:29:37 +02:00
|
|
|
void ui_draw_layout_panels_backdrop(const ARegion *region,
|
|
|
|
|
const Panel *panel,
|
|
|
|
|
const float radius,
|
|
|
|
|
float subpanel_backcolor[4]);
|
|
|
|
|
void ui_panel_drag_collapse_handler_add(const bContext *C, const bool was_open);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_panel_tag_search_filter_match(Panel *panel);
|
2024-05-24 20:29:37 +02:00
|
|
|
/** Toggles layout panel open state and returns the new state. */
|
|
|
|
|
bool ui_layout_panel_toggle_open(const bContext *C, LayoutPanelHeader *header);
|
|
|
|
|
LayoutPanelHeader *ui_layout_panel_header_under_mouse(const Panel &panel, const int my);
|
|
|
|
|
/** Apply scroll to layout panels when the main panel is used in popups. */
|
|
|
|
|
void ui_layout_panel_popup_scroll_apply(Panel *panel, const float dy);
|
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-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Draws in resolution of 48x4 colors.
|
|
|
|
|
*/
|
2022-01-07 11:38:08 +11:00
|
|
|
void ui_draw_gradient(const rcti *rect, const float hsv[3], eButGradientType type, float alpha);
|
2010-01-21 00:00:45 +00:00
|
|
|
|
2023-09-26 17:12:37 +02:00
|
|
|
/**
|
|
|
|
|
* Draws rounded corner segments but inverted. Imagine each corner like a filled right triangle,
|
|
|
|
|
* just that the hypotenuse is nicely curved inwards (towards the right angle of the triangle).
|
|
|
|
|
*
|
|
|
|
|
* Useful for connecting orthogonal shapes with a rounded corner, which can look quite nice.
|
|
|
|
|
*/
|
|
|
|
|
void ui_draw_rounded_corners_inverted(const rcti &rect,
|
|
|
|
|
const float rad,
|
|
|
|
|
const blender::float4 color);
|
|
|
|
|
|
2019-01-04 11:05:53 +11:00
|
|
|
void ui_draw_but_TAB_outline(const rcti *rect,
|
|
|
|
|
float rad,
|
|
|
|
|
uchar highlight[3],
|
|
|
|
|
uchar highlight_fade[3]);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_HISTOGRAM(ARegion *region,
|
2019-01-04 09:58:03 +11:00
|
|
|
uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *wcol,
|
2024-07-27 13:20:43 +10:00
|
|
|
const rcti *recti);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_WAVEFORM(ARegion *region,
|
2019-01-04 09:58:03 +11:00
|
|
|
uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *wcol,
|
2024-07-27 13:20:43 +10:00
|
|
|
const rcti *recti);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_VECTORSCOPE(ARegion *region,
|
2019-01-04 09:58:03 +11:00
|
|
|
uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *wcol,
|
2024-07-27 13:20:43 +10:00
|
|
|
const rcti *recti);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_COLORBAND(uiBut *but, const uiWidgetColors *wcol, const rcti *rect);
|
|
|
|
|
void ui_draw_but_UNITVEC(uiBut *but, const uiWidgetColors *wcol, const rcti *rect, float radius);
|
|
|
|
|
void ui_draw_but_CURVE(ARegion *region, uiBut *but, const uiWidgetColors *wcol, const rcti *rect);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2022-04-11 11:41:00 +10:00
|
|
|
* Draws the curve profile widget. Somewhat similar to ui_draw_but_CURVE.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_CURVEPROFILE(ARegion *region,
|
2019-11-20 16:12:32 -05:00
|
|
|
uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *wcol,
|
2019-11-20 16:12:32 -05:00
|
|
|
const rcti *rect);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but_IMAGE(ARegion *region, uiBut *but, const uiWidgetColors *wcol, const rcti *rect);
|
|
|
|
|
void ui_draw_but_TRACKPREVIEW(ARegion *region,
|
2019-01-04 09:58:03 +11:00
|
|
|
uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *wcol,
|
2024-07-27 13:20:43 +10:00
|
|
|
const rcti *recti);
|
2009-04-06 15:44:30 +00:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_undo.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Start the undo stack.
|
|
|
|
|
*
|
|
|
|
|
* \note The current state should be pushed immediately after calling this.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
uiUndoStack_Text *ui_textedit_undo_stack_create();
|
2024-07-27 13:20:43 +10:00
|
|
|
void ui_textedit_undo_stack_destroy(uiUndoStack_Text *stack);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Push the information in the arguments to a new state in the undo stack.
|
|
|
|
|
*
|
|
|
|
|
* \note Currently the total length of the undo stack is not limited.
|
|
|
|
|
*/
|
2024-07-27 13:20:43 +10:00
|
|
|
void ui_textedit_undo_push(uiUndoStack_Text *stack, const char *text, int cursor_index);
|
|
|
|
|
const char *ui_textedit_undo(uiUndoStack_Text *stack, int direction, int *r_cursor_index);
|
2020-05-12 10:55:46 +10:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_handlers.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2025-02-18 15:57:38 +01:00
|
|
|
void ui_but_handle_data_free(uiHandleButtonData **data);
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_handle_afterfunc_add_operator(wmOperatorType *ot, wmOperatorCallContext opcontext);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Assumes event type is MOUSEPAN.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_pan_to_scroll(const wmEvent *event, int *type, int *val);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2023-07-31 11:50:54 +10:00
|
|
|
* Exported to `interface.cc`: #UI_but_active_only()
|
2021-12-09 00:55:11 +11:00
|
|
|
* \note The region is only for the button.
|
|
|
|
|
* The context needs to be set by the caller.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_activate_event(bContext *C, ARegion *region, uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Simulate moving the mouse over a button (or navigating to it with arrow keys).
|
|
|
|
|
*
|
|
|
|
|
* exported so menus can start with a highlighted button,
|
|
|
|
|
* even if the mouse isn't over it
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_activate_over(bContext *C, ARegion *region, uiBut *but);
|
|
|
|
|
void ui_but_execute_begin(bContext *C, ARegion *region, uiBut *but, void **active_back);
|
|
|
|
|
void ui_but_execute_end(bContext *C, ARegion *region, uiBut *but, void *active_back);
|
|
|
|
|
void ui_but_active_free(const bContext *C, uiBut *but);
|
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
|
|
|
void ui_but_semi_modal_state_free(const bContext *C, uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* In some cases we may want to update the view (#View2D) in-between layout definition and drawing.
|
|
|
|
|
* E.g. to make sure a button is visible while editing.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_update_view_for_active(const bContext *C, const uiBlock *block);
|
|
|
|
|
int ui_but_menu_direction(uiBut *but);
|
|
|
|
|
void ui_but_text_password_hide(char password_str[128], uiBut *but, bool restore);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Finds the pressed button in an aligned row (typically an expanded enum).
|
|
|
|
|
*
|
|
|
|
|
* \param direction: Use when there may be multiple buttons pressed.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_but_find_select_in_enum(uiBut *but, int direction);
|
2019-03-22 18:51:04 +11:00
|
|
|
bool ui_but_is_editing(const uiBut *but);
|
2022-11-26 00:21:17 -06:00
|
|
|
float ui_block_calc_pie_segment(uiBlock *block, const float event_xy[2]);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/* XXX, this code will shorten any allocated string to 'UI_MAX_NAME_STR'
|
|
|
|
|
* since this is really long its unlikely to be an issue,
|
|
|
|
|
* but this could be supported */
|
2022-01-07 11:38:08 +11:00
|
|
|
void ui_but_add_shortcut(uiBut *but, const char *shortcut_str, bool do_strip);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_clipboard_free();
|
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
|
|
|
bool ui_but_rna_equals(const uiBut *a, const uiBut *b);
|
|
|
|
|
bool ui_but_rna_equals_ex(const uiBut *but,
|
|
|
|
|
const PointerRNA *ptr,
|
|
|
|
|
const PropertyRNA *prop,
|
|
|
|
|
int index);
|
2014-02-08 09:03:25 +11:00
|
|
|
uiBut *ui_but_find_old(uiBlock *block_old, const uiBut *but_new);
|
2020-09-04 20:59:13 +02:00
|
|
|
uiBut *ui_but_find_new(uiBlock *block_new, const uiBut *but_old);
|
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-12-07 00:58:17 +01:00
|
|
|
#ifdef WITH_INPUT_IME
|
|
|
|
|
void ui_but_ime_reposition(uiBut *but, int x, int y, bool complete);
|
2023-10-08 14:28:28 +11:00
|
|
|
const wmIMEData *ui_but_ime_data_get(uiBut *but);
|
2014-12-07 00:58:17 +01:00
|
|
|
#endif
|
|
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_widgets.cc` */
|
2018-04-05 18:51:08 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/** Widget shader parameters, must match the shader layout. */
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiWidgetBaseParameters {
|
2018-04-05 18:51:08 +02:00
|
|
|
rctf recti, rect;
|
|
|
|
|
float radi, rad;
|
|
|
|
|
float facxi, facyi;
|
|
|
|
|
float round_corners[4];
|
|
|
|
|
float color_inner1[4], color_inner2[4];
|
|
|
|
|
float color_outline[4], color_emboss[4];
|
|
|
|
|
float color_tria[4];
|
|
|
|
|
float tria1_center[2], tria2_center[2];
|
|
|
|
|
float tria1_size, tria2_size;
|
2018-04-28 02:51:27 +02:00
|
|
|
float shade_dir;
|
|
|
|
|
/* We pack alpha check and discard factor in alpha_discard.
|
|
|
|
|
* If the value is negative then we do alpha check.
|
2018-05-03 09:56:20 +02:00
|
|
|
* The absolute value itself is the discard factor.
|
2020-11-06 11:25:27 +11:00
|
|
|
* Initialize value to 1.0f if you don't want discard. */
|
2018-04-28 02:51:27 +02:00
|
|
|
float alpha_discard;
|
2020-06-22 19:57:53 +02:00
|
|
|
float tria_type;
|
|
|
|
|
float _pad[3];
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2018-04-05 18:51:08 +02:00
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
ROUNDBOX_TRIA_NONE = 0,
|
|
|
|
|
ROUNDBOX_TRIA_ARROWS,
|
|
|
|
|
ROUNDBOX_TRIA_SCROLL,
|
|
|
|
|
ROUNDBOX_TRIA_MENU,
|
|
|
|
|
ROUNDBOX_TRIA_CHECK,
|
2018-04-15 21:14:10 +02:00
|
|
|
ROUNDBOX_TRIA_HOLD_ACTION_ARROW,
|
2023-07-17 19:37:15 +02:00
|
|
|
ROUNDBOX_TRIA_DASH,
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-04-05 18:51:08 +02:00
|
|
|
ROUNDBOX_TRIA_MAX, /* don't use */
|
|
|
|
|
};
|
|
|
|
|
|
2024-03-26 03:06:25 +01:00
|
|
|
blender::gpu::Batch *ui_batch_roundbox_widget_get();
|
|
|
|
|
blender::gpu::Batch *ui_batch_roundbox_shadow_get();
|
2018-04-05 18:51:08 +02:00
|
|
|
|
2024-09-26 15:02:59 +10:00
|
|
|
void ui_draw_menu_back(uiStyle *style, uiBlock *block, const rcti *rect);
|
|
|
|
|
void ui_draw_popover_back(ARegion *region, uiStyle *style, uiBlock *block, const rcti *rect);
|
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
|
|
|
void ui_draw_pie_center(uiBlock *block);
|
2022-11-26 00:21:17 -06:00
|
|
|
const uiWidgetColors *ui_tooltip_get_theme();
|
2018-06-12 08:14:13 +02:00
|
|
|
|
2019-03-22 17:56:58 +11:00
|
|
|
void ui_draw_widget_menu_back_color(const rcti *rect, bool use_shadow, const float color[4]);
|
|
|
|
|
void ui_draw_widget_menu_back(const rcti *rect, bool use_shadow);
|
2024-09-26 15:02:59 +10:00
|
|
|
void ui_draw_tooltip_background(const uiStyle *style, uiBlock *block, const rcti *rect);
|
2009-06-03 18:31:37 +00:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Conversion from old to new buttons, so still messy.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_but(const bContext *C, ARegion *region, uiStyle *style, uiBut *but, rcti *rect);
|
2009-04-09 18:11:18 +00:00
|
|
|
|
2021-01-25 22:54:00 +01:00
|
|
|
/**
|
|
|
|
|
* Info about what the separator character separates, used to decide between different drawing
|
|
|
|
|
* styles. E.g. we never want a shortcut string to be clipped, but other hint strings can be
|
|
|
|
|
* clipped.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
enum uiMenuItemSeparatorType {
|
2021-01-25 22:54:00 +01:00
|
|
|
UI_MENU_ITEM_SEPARATOR_NONE,
|
|
|
|
|
/** Separator is used to indicate shortcut string of this item. Shortcut string will not get
|
|
|
|
|
* clipped. */
|
|
|
|
|
UI_MENU_ITEM_SEPARATOR_SHORTCUT,
|
|
|
|
|
/** Separator is used to indicate some additional hint to display for this item. Hint string will
|
|
|
|
|
* get clipped before the normal text. */
|
|
|
|
|
UI_MENU_ITEM_SEPARATOR_HINT,
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Helper call to draw a menu item without a button.
|
|
|
|
|
*
|
2025-05-07 02:32:13 +02:00
|
|
|
* \param back_rect: Used to draw/leave out the backdrop of the menu item. Useful when layering
|
|
|
|
|
* multiple items with different formatting like in search menus.
|
2022-05-21 00:29:32 +02:00
|
|
|
* \param but_flag: Button flags (#uiBut.flag) indicating the state of the item, typically
|
2023-10-25 18:36:27 +02:00
|
|
|
* #UI_HOVER, #UI_BUT_DISABLED, #UI_BUT_INACTIVE.
|
2021-12-09 00:55:11 +11:00
|
|
|
* \param separator_type: The kind of separator which controls if and how the string is clipped.
|
2022-05-21 00:29:32 +02:00
|
|
|
* \param r_xmax: The right hand position of the text, this takes into the icon, padding and text
|
|
|
|
|
* clipping when there is not enough room to display the full text.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_menu_item(const uiFontStyle *fstyle,
|
2019-01-04 09:58:03 +11:00
|
|
|
rcti *rect,
|
2025-05-07 02:32:13 +02:00
|
|
|
rcti *back_rect,
|
|
|
|
|
float zoom,
|
|
|
|
|
bool use_unpadded,
|
2019-01-04 09:58:03 +11:00
|
|
|
const char *name,
|
|
|
|
|
int iconid,
|
2022-05-21 00:29:32 +02:00
|
|
|
int but_flag,
|
2021-01-25 22:54:00 +01:00
|
|
|
uiMenuItemSeparatorType separator_type,
|
2020-04-17 11:16:48 +10:00
|
|
|
int *r_xmax);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_preview_item(const uiFontStyle *fstyle,
|
2021-07-13 17:30:34 +02:00
|
|
|
rcti *rect,
|
2025-05-07 02:32:13 +02:00
|
|
|
float zoom,
|
2021-07-13 17:30:34 +02:00
|
|
|
const char *name,
|
|
|
|
|
int iconid,
|
2022-05-21 00:29:32 +02:00
|
|
|
int but_flag,
|
2021-07-13 17:30:34 +02:00
|
|
|
eFontStyle_Align text_align);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Version of #ui_draw_preview_item() that does not draw the menu background and item text based on
|
|
|
|
|
* state. It just draws the preview and text directly.
|
2023-08-03 16:54:39 +02:00
|
|
|
*
|
|
|
|
|
* \param draw_as_icon: Instead of stretching the preview/icon to the available width/height, draw
|
|
|
|
|
* it at the standard icon size. Mono-icons will draw with \a text_col or the
|
|
|
|
|
* corresponding theme override for this type of icon.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_draw_preview_item_stateless(const uiFontStyle *fstyle,
|
2021-07-13 17:30:34 +02:00
|
|
|
rcti *rect,
|
2024-01-22 14:54:44 -05:00
|
|
|
blender::StringRef name,
|
2021-07-13 17:30:34 +02:00
|
|
|
int iconid,
|
|
|
|
|
const uchar text_col[4],
|
2025-03-14 16:43:12 +01:00
|
|
|
eFontStyle_Align text_align,
|
|
|
|
|
const bool add_padding);
|
2009-06-02 18:10:06 +00:00
|
|
|
|
2013-01-17 18:59:19 +00:00
|
|
|
#define UI_TEXT_MARGIN_X 0.4f
|
2023-03-17 04:19:05 +01:00
|
|
|
#define UI_POPUP_MARGIN (UI_SCALE_FAC * 12)
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Margin at top of screen for popups.
|
|
|
|
|
* Note this value must be sufficient to draw a popover arrow to avoid cropping it.
|
|
|
|
|
*/
|
2023-03-17 04:19:05 +01:00
|
|
|
#define UI_POPUP_MENU_TOP (int)(10 * UI_SCALE_FAC)
|
2013-01-17 18:59:19 +00:00
|
|
|
|
2018-04-20 15:15:10 +02:00
|
|
|
#define UI_PIXEL_AA_JITTER 8
|
2018-07-31 20:44:49 +10:00
|
|
|
extern const float ui_pixel_jitter[UI_PIXEL_AA_JITTER][2];
|
2018-04-20 15:15:10 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_style.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called on each startup.blend read,
|
|
|
|
|
* reading without #uiFont will create one.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void uiStyleInit();
|
2009-04-02 15:01:11 +00:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_icons.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_icon_ensure_deferred(const bContext *C, int icon_id, bool big);
|
2025-02-03 16:03:06 +01:00
|
|
|
/** Is \a icon_id a preview icon that is being loaded/rendered? */
|
|
|
|
|
bool ui_icon_is_preview_deferred_loading(int icon_id, bool big);
|
2022-11-26 00:21:17 -06:00
|
|
|
int ui_id_icon_get(const bContext *C, ID *id, bool big);
|
2009-06-25 15:41:27 +00:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_icons_event.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2024-08-10 11:32:40 +10:00
|
|
|
float ui_event_icon_offset(int icon_id);
|
2024-08-05 02:42:26 +02:00
|
|
|
|
|
|
|
|
void icon_draw_rect_input(
|
|
|
|
|
float x, float y, int w, int h, int icon_id, float aspect, float alpha, bool inverted);
|
2018-07-08 11:57:59 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `resources.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_resources_init();
|
|
|
|
|
void ui_resources_free();
|
2.5
Summary of ain features:
- Themes and Styles are now editable.
- CTRL+U "Save user defaults" now goes to new .B25.blend, so you
can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it
reads the regular .B.blend
- Press Tkey in 3d window for (unfinished) toolbar WIP. It now only
shows the last operator, if appropriate.
Nkey properties moved to the other side.
A lot of work was done on removing old themes for good and properly
getting it work with the 2.5 region system. Here's some notes;
- Buttons now all have a complete set of colors, based on button classifications
(See outliner -> user prefs -> Interface
- Theme colors have been extended with basic colors for region types.
Currently colors are defined for Window, Header, List/Channels and
for Button/Tool views.
The screen manager handles this btw, so a TH_BACK will always pick the
right backdrop color.
- Menu backdrops are in in Button theme colors. Floating Panels will be in
the per-space type Themes.
- Styles were added in RNA too, but only for the font settings now.
Only Panel font, widget font and widget-label work now. The 'group label'
will be for templates mostly.
Style settings will be expanded with spacing defaults, label conventions,
etc.
- Label text colors are stored in per-space Theme too, to make sure they fit.
Same goes for Panel title color.
Note that 'shadow' for fonts can conflict with text colors; shadow color is
currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_layout.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2009-06-27 01:15:31 +00:00
|
|
|
void ui_layout_add_but(uiLayout *layout, uiBut *but);
|
2021-10-06 11:20:15 +02:00
|
|
|
void ui_layout_remove_but(uiLayout *layout, const uiBut *but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \return true if the button was successfully replaced.
|
|
|
|
|
*/
|
2020-08-07 14:34:11 +02:00
|
|
|
bool ui_layout_replace_but_ptr(uiLayout *layout, const void *old_but_ptr, uiBut *new_but);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
2022-03-17 17:45:29 +01:00
|
|
|
* \note May reallocate \a but, so the possibly new address is returned. May also override the
|
|
|
|
|
* #UI_BUT_DISABLED flag depending on if a search pointer-property pair was provided/found.
|
2021-12-09 00:55:11 +11:00
|
|
|
*/
|
2020-08-07 14:34:11 +02:00
|
|
|
uiBut *ui_but_add_search(uiBut *but,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
PointerRNA *searchptr,
|
2022-04-04 03:50:55 +02:00
|
|
|
PropertyRNA *searchprop,
|
|
|
|
|
bool results_are_suggestions);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check all buttons defined in this layout,
|
|
|
|
|
* and set any button flagged as UI_BUT_LIST_ITEM as active/selected.
|
|
|
|
|
* Needed to handle correctly text colors of active (selected) list item.
|
|
|
|
|
*/
|
Fix [#35750] list items in properties editor (text colors not following list item theme).
Issue goes back since we stopped using LISTROW button to draw item's name (i.e. since we have custom buttons in list items!).
This commit:
* Adds a new flag to uiBlock, UI_BLOCK_LIST_ITEM, to mark blocks used for each list item.
* Adds a new button type, LISTLABEL, which basically behaves exactly as LABEL, but uses wcol_list_item color set.
* When uiItemL is called, it checks whether current block has UI_BLOCK_LIST_ITEM set, and if so, switch produced button to LISTLABEL type.
* Adds a new helper func, ui_layout_list_set_labels_active, called after the active list item has been "drawn", to set all LISTLABEL buttons as UI_SELECT.
Note custom widget_state_label() was removed, in interface_widgets.c, as it did nothing more than default widget_state().
Thanks to Brecht for the review and advices.
2013-06-26 07:28:55 +00:00
|
|
|
void ui_layout_list_set_labels_active(uiLayout *layout);
|
2018-05-25 15:46:22 +02:00
|
|
|
/* menu callback */
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_item_menutype_func(bContext *C, uiLayout *layout, void *arg_mt);
|
|
|
|
|
void ui_item_paneltype_func(bContext *C, uiLayout *layout, void *arg_pt);
|
2009-04-10 14:06:24 +00:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_button_group.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Every function that adds a set of buttons must create another group,
|
|
|
|
|
* then #ui_def_but adds buttons to the current group (the last).
|
|
|
|
|
*/
|
2021-01-04 17:35:14 -06:00
|
|
|
void ui_block_new_button_group(uiBlock *block, uiButtonGroupFlag flag);
|
2020-10-02 17:00:41 -05:00
|
|
|
void ui_button_group_add_but(uiBlock *block, uiBut *but);
|
2022-12-18 21:45:32 -06:00
|
|
|
void ui_button_group_replace_but_ptr(uiBlock *block, const uiBut *old_but_ptr, uiBut *new_but);
|
2020-10-02 17:00:41 -05:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_drag.cc` */
|
2022-05-31 15:06:57 +02:00
|
|
|
|
|
|
|
|
void ui_but_drag_free(uiBut *but);
|
|
|
|
|
bool ui_but_drag_is_draggable(const uiBut *but);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_drag_start(bContext *C, uiBut *but);
|
2022-05-31 15:06:57 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_align.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2015-11-07 17:36:10 +11:00
|
|
|
bool ui_but_can_align(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2022-11-26 00:21:17 -06:00
|
|
|
int ui_but_align_opposite_to_area_align_get(const ARegion *region) ATTR_WARN_UNUSED_RESULT;
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Compute the alignment of all 'align groups' of buttons in given block.
|
|
|
|
|
*
|
|
|
|
|
* This is using an order-independent algorithm,
|
|
|
|
|
* i.e. alignment of buttons should be OK regardless of order in which
|
|
|
|
|
* they are added to the block.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_block_align_calc(uiBlock *block, const ARegion *region);
|
2015-11-07 17:31:28 +11:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_anim.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_anim_flag(uiBut *but, const AnimationEvalContext *anim_eval_context);
|
|
|
|
|
void ui_but_anim_copy_driver(bContext *C);
|
|
|
|
|
void ui_but_anim_paste_driver(bContext *C);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* \a str can be NULL to only perform check if \a but has an expression at all.
|
|
|
|
|
* \return if button has an expression.
|
|
|
|
|
*/
|
2023-05-07 15:22:58 +10:00
|
|
|
bool ui_but_anim_expression_get(uiBut *but, char *str, size_t str_maxncpy);
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_set(uiBut *but, const char *str);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Create new expression for button (i.e. a "scripted driver"), if it can be created.
|
|
|
|
|
*/
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_create(uiBut *but, const char *str);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_anim_autokey(bContext *C, uiBut *but, Scene *scene, float cfra);
|
2018-06-16 18:26:34 +02:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_but_anim_decorate_cb(bContext *C, void *arg_but, void *arg_dummy);
|
2020-08-07 14:34:11 +02:00
|
|
|
void ui_but_anim_decorate_update_from_flag(uiButDecorator *but);
|
2009-04-03 23:30:32 +00:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_query.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2019-03-22 18:51:04 +11:00
|
|
|
bool ui_but_is_editable(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_editable_as_text(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_is_toggle(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Can we mouse over the button or is it hidden/disabled/layout.
|
|
|
|
|
* \note ctrl is kind of a hack currently,
|
|
|
|
|
* so that non-embossed UI_BTYPE_TEXT button behaves as a label when ctrl is not pressed.
|
|
|
|
|
*/
|
2022-05-13 23:41:03 +10:00
|
|
|
bool ui_but_is_interactive_ex(const uiBut *but, const bool labeledit, const bool for_tooltip);
|
2022-01-07 11:38:08 +11:00
|
|
|
bool ui_but_is_interactive(const uiBut *but, bool labeledit) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
bool ui_but_is_popover_once_compat(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_has_array_value(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2020-04-14 23:44:15 +10:00
|
|
|
int ui_but_icon(const uiBut *but);
|
2019-03-22 18:51:04 +11:00
|
|
|
void ui_but_pie_dir(RadialDirection dir, float vec[2]);
|
|
|
|
|
|
|
|
|
|
bool ui_but_is_cursor_warp(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
|
|
|
|
bool ui_but_contains_pt(const uiBut *but, float mx, float my) ATTR_WARN_UNUSED_RESULT;
|
2019-04-23 16:43:50 +10:00
|
|
|
bool ui_but_contains_rect(const uiBut *but, const rctf *rect);
|
2019-03-22 18:51:04 +11:00
|
|
|
bool ui_but_contains_point_px_icon(const uiBut *but,
|
2022-11-26 00:21:17 -06:00
|
|
|
ARegion *region,
|
|
|
|
|
const wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_but_contains_point_px(const uiBut *but, const ARegion *region, const int xy[2])
|
2021-10-20 20:49:02 -03:00
|
|
|
ATTR_NONNULL(1, 2, 3) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_list_find_mouse_over(const ARegion *region,
|
|
|
|
|
const wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_list_find_from_row(const ARegion *region, const uiBut *row_but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_list_row_find_mouse_over(const ARegion *region, const int xy[2])
|
2021-10-20 20:49:02 -03:00
|
|
|
ATTR_NONNULL(1, 2) ATTR_WARN_UNUSED_RESULT;
|
2023-08-06 15:57:24 +10:00
|
|
|
uiBut *ui_list_row_find_index(const ARegion *region,
|
|
|
|
|
int index,
|
|
|
|
|
uiBut *listbox) ATTR_WARN_UNUSED_RESULT;
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_view_item_find_mouse_over(const ARegion *region, const int xy[2]) ATTR_NONNULL(1, 2);
|
|
|
|
|
uiBut *ui_view_item_find_active(const ARegion *region);
|
2024-07-01 20:21:25 +02:00
|
|
|
uiBut *ui_view_item_find_search_highlight(const ARegion *region);
|
2021-07-09 21:46:55 +02:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
using uiButFindPollFn = bool (*)(const uiBut *but, const void *customdata);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* x and y are only used in case event is NULL.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_but_find_mouse_over_ex(const ARegion *region,
|
2021-10-20 20:49:02 -03:00
|
|
|
const int xy[2],
|
2022-01-07 11:38:08 +11:00
|
|
|
bool labeledit,
|
2022-05-13 23:41:03 +10:00
|
|
|
bool for_tooltip,
|
2021-07-09 21:46:55 +02:00
|
|
|
const uiButFindPollFn find_poll,
|
2021-10-20 20:49:02 -03:00
|
|
|
const void *find_custom_data)
|
|
|
|
|
ATTR_NONNULL(1, 2) ATTR_WARN_UNUSED_RESULT;
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_but_find_mouse_over(const ARegion *region, const wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_but_find_rect_over(const ARegion *region, const rcti *rect_px) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBut *ui_list_find_mouse_over_ex(const ARegion *region, const int xy[2])
|
2021-10-20 20:49:02 -03:00
|
|
|
ATTR_NONNULL(1, 2) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
|
|
|
|
bool ui_but_contains_password(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
2024-01-22 14:54:44 -05:00
|
|
|
blender::StringRef ui_but_drawstr_without_sep_char(const uiBut *but) ATTR_NONNULL();
|
2020-11-18 15:09:34 +11:00
|
|
|
size_t ui_but_drawstr_len_without_sep_char(const uiBut *but);
|
|
|
|
|
size_t ui_but_tip_len_only_first_line(const uiBut *but);
|
|
|
|
|
|
2019-03-22 18:51:04 +11:00
|
|
|
uiBut *ui_but_prev(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_but_next(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_but_first(uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
uiBut *ui_but_last(uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
2021-07-09 21:46:55 +02:00
|
|
|
uiBut *ui_block_active_but_get(const uiBlock *block);
|
2019-03-22 18:51:04 +11:00
|
|
|
bool ui_block_is_menu(const uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_block_is_popover(const uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_block_is_pie_menu(const uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_block_is_popup_any(const uiBlock *block) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBlock *ui_block_find_mouse_over_ex(const ARegion *region, const int xy[2], bool only_clip)
|
2021-10-20 20:49:02 -03:00
|
|
|
ATTR_NONNULL(1, 2);
|
2022-11-26 00:21:17 -06:00
|
|
|
uiBlock *ui_block_find_mouse_over(const ARegion *region, const wmEvent *event, bool only_clip);
|
|
|
|
|
|
|
|
|
|
uiBut *ui_region_find_first_but_test_flag(ARegion *region, int flag_include, int flag_exclude);
|
|
|
|
|
uiBut *ui_region_find_active_but(ARegion *region) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_region_contains_point_px(const ARegion *region, const int xy[2])
|
2021-10-20 20:49:02 -03:00
|
|
|
ATTR_NONNULL(1, 2) ATTR_WARN_UNUSED_RESULT;
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_region_contains_rect_px(const ARegion *region, const rcti *rect_px);
|
2018-06-30 10:36:40 +02:00
|
|
|
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* Check if the cursor is over any popups.
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
ARegion *ui_screen_region_find_mouse_over_ex(bScreen *screen, const int xy[2]) ATTR_NONNULL(1, 2);
|
|
|
|
|
ARegion *ui_screen_region_find_mouse_over(bScreen *screen, const wmEvent *event);
|
2019-07-31 19:10:44 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_context_menu.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_popup_context_menu_for_button(bContext *C, uiBut *but, const wmEvent *event);
|
2021-12-09 00:55:11 +11:00
|
|
|
/**
|
|
|
|
|
* menu to show when right clicking on the panel header
|
|
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_popup_context_menu_for_panel(bContext *C, ARegion *region, Panel *panel);
|
2018-06-24 10:01:13 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/interface_eyedropper.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
wmKeyMap *eyedropper_modal_keymap(wmKeyConfig *keyconf);
|
|
|
|
|
wmKeyMap *eyedropper_colorband_modal_keymap(wmKeyConfig *keyconf);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/eyedropper_color.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void UI_OT_eyedropper_color(wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_eyedropper_colorband.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2024-04-17 12:44:53 -04:00
|
|
|
namespace blender::ui {
|
2022-11-26 00:21:17 -06:00
|
|
|
void UI_OT_eyedropper_colorramp(wmOperatorType *ot);
|
|
|
|
|
void UI_OT_eyedropper_colorramp_point(wmOperatorType *ot);
|
2024-09-26 10:05:09 +02:00
|
|
|
|
|
|
|
|
void UI_OT_eyedropper_bone(wmOperatorType *ot);
|
|
|
|
|
|
2024-04-17 12:44:53 -04:00
|
|
|
} // namespace blender::ui
|
2017-12-12 15:16:13 +11:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/eyedropper_datablock.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void UI_OT_eyedropper_id(wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/eyedropper_depth.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void UI_OT_eyedropper_depth(wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/eyedropper_driver.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void UI_OT_eyedropper_driver(wmOperatorType *ot);
|
2013-10-08 15:07:52 +00:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `eyedroppers/eyedropper_grease_pencil_colorr.cc` */
|
2024-08-19 11:27:49 +02:00
|
|
|
|
|
|
|
|
void UI_OT_eyedropper_grease_pencil_color(wmOperatorType *ot);
|
|
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `templates/interface_template_asset_shelf_popover.cc` */
|
2024-07-07 20:00:35 +02:00
|
|
|
std::optional<blender::StringRefNull> UI_asset_shelf_idname_from_button_context(const uiBut *but);
|
|
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `templates/interface_template_asset_view.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiListType *UI_UL_asset_view();
|
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
|
|
|
|
2017-05-12 01:42:42 +02:00
|
|
|
/**
|
2020-05-07 23:16:05 +10:00
|
|
|
* For use with #ui_rna_collection_search_update_fn.
|
2017-05-12 01:42:42 +02:00
|
|
|
*/
|
2022-11-26 00:21:17 -06:00
|
|
|
struct uiRNACollectionSearch {
|
2017-05-12 01:42:42 +02:00
|
|
|
PointerRNA target_ptr;
|
|
|
|
|
PropertyRNA *target_prop;
|
|
|
|
|
|
|
|
|
|
PointerRNA search_ptr;
|
|
|
|
|
PropertyRNA *search_prop;
|
|
|
|
|
|
2020-04-08 23:08:32 +02:00
|
|
|
uiBut *search_but;
|
2025-05-13 11:13:48 +10:00
|
|
|
/** Let `UI_butstore_*` API update search_but pointer above over redraws. */
|
2020-04-08 23:08:32 +02:00
|
|
|
uiButStore *butstore;
|
2025-05-13 11:13:48 +10:00
|
|
|
/** Block has to be stored for freeing but-store (#uiBut::block doesn't work with undo). */
|
2020-04-08 23:08:32 +02:00
|
|
|
uiBlock *butstore_block;
|
2022-11-26 00:21:17 -06:00
|
|
|
};
|
2022-01-07 11:38:08 +11:00
|
|
|
void ui_rna_collection_search_update_fn(
|
2022-11-26 00:21:17 -06:00
|
|
|
const bContext *C, void *arg, const char *str, uiSearchItems *items, bool is_first);
|
2017-05-12 01:42:42 +02:00
|
|
|
|
2023-07-31 11:50:54 +10:00
|
|
|
/* `interface_ops.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
bool ui_jump_to_target_button_poll(bContext *C);
|
2019-03-15 10:49:26 -03:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `interface_query.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_interface_tag_script_reload_queries();
|
2021-03-01 16:24:07 +01:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `views/interface_view.cc` */
|
2021-12-09 00:55:11 +11:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_block_free_views(uiBlock *block);
|
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 ui_block_views_end(ARegion *region, const uiBlock *block);
|
|
|
|
|
void ui_block_view_persistent_state_restore(const ARegion ®ion,
|
|
|
|
|
const uiBlock &block,
|
|
|
|
|
blender::ui::AbstractView &view);
|
2022-11-26 00:21:17 -06:00
|
|
|
void ui_block_views_listen(const uiBlock *block, const wmRegionListenerParams *listener_params);
|
2023-07-06 17:00:44 +02:00
|
|
|
void ui_block_views_draw_overlays(const ARegion *region, const uiBlock *block);
|
2024-03-08 09:16:00 -05:00
|
|
|
blender::ui::AbstractView *ui_block_view_find_matching_in_old_block(
|
|
|
|
|
const uiBlock &new_block, const blender::ui::AbstractView &new_view);
|
UI: Add AbstractView base class for views, unify reconstruction in there
No user visible changes expected.
There's plenty of duplicated code in the grid and the tree view, and I expect
this to become more. This starts the process of unifying these parts, which
should also make it easier to add new views. Complexity in the view classes is
reduced, and some type shenanigans for C compatibility and general view
management can be removed, since there is now a common base type.
For the start this ports some of the view reconstruction, where the view and
its items are compared to the version of itself in the previous redraw, so that
state (highlighted, active, renaming, collapsed, ...) can be preserved.
Notifier listening is also ported.
2022-07-02 21:49:21 +02: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
|
|
|
uiButViewItem *ui_block_view_find_matching_view_item_but_in_old_block(
|
2024-03-08 09:16:00 -05:00
|
|
|
const uiBlock &new_block, const blender::ui::AbstractViewItem &new_item);
|
2021-09-23 18:56:29 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `views/abstract_view_item.cc` */
|
2023-07-06 17:00:44 +02:00
|
|
|
|
2024-03-08 09:16:00 -05:00
|
|
|
void ui_view_item_swap_button_pointers(blender::ui::AbstractViewItem &a,
|
|
|
|
|
blender::ui::AbstractViewItem &b);
|
2023-07-06 17:00:44 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/* `views/interface_templates.cc` */
|
2022-04-04 13:17:03 +10:00
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
uiListType *UI_UL_cache_file_layers();
|
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
|
|
|
|
2022-11-26 00:21:17 -06:00
|
|
|
ID *ui_template_id_liboverride_hierarchy_make(
|
|
|
|
|
bContext *C, Main *bmain, ID *owner_id, ID *id, const char **r_undo_push_label);
|
2024-04-29 18:34:57 +02:00
|
|
|
|
2025-05-13 11:13:48 +10:00
|
|
|
/**
|
|
|
|
|
* Functions in this namespace are only exposed for unit testing purposes, and
|
|
|
|
|
* should not be used outside of the files where they are defined.
|
|
|
|
|
*/
|
2024-04-29 18:34:57 +02:00
|
|
|
namespace blender::interface::internal {
|
|
|
|
|
|
2024-04-30 12:52:52 +10:00
|
|
|
/**
|
|
|
|
|
* Get the driver(s) of the given property.
|
|
|
|
|
*
|
2024-05-03 11:32:43 +10:00
|
|
|
* \note intended to be used in conjunction with `paste_property_drivers()` below.
|
2024-04-30 12:52:52 +10:00
|
|
|
*
|
|
|
|
|
* \param ptr: The RNA pointer of the property.
|
|
|
|
|
* \param prop: The property RNA of the property.
|
|
|
|
|
* \param get_all: Whether to get all drivers of an array property, or just the
|
|
|
|
|
* one specified by `index`. Ignored if the property is not an array property.
|
|
|
|
|
* \param index: Which element of an array property to get. Ignored if `get_all`
|
|
|
|
|
* is true or if the property is not an array properly.
|
|
|
|
|
* \param r_is_array_prop: Output parameter, that stores whether the passed
|
|
|
|
|
* property is an array property or not.
|
|
|
|
|
*
|
|
|
|
|
* \returns A vector of pointers to the drivers of the property. It will be
|
|
|
|
|
* zero-sized if no drivers were fetched (e.g. if the property had no drivers).
|
|
|
|
|
* Otherwise the vector will be the size of the underlying property (e.g. 4 for
|
|
|
|
|
* an array property with 4 elements, 1 for a non-array property). For array
|
2024-05-02 16:44:10 +10:00
|
|
|
* properties, elements without drivers will be null.
|
2024-04-30 12:52:52 +10:00
|
|
|
*/
|
2024-04-29 18:34:57 +02:00
|
|
|
blender::Vector<FCurve *> get_property_drivers(
|
|
|
|
|
PointerRNA *ptr, PropertyRNA *prop, bool get_all, int index, bool *r_is_array_prop);
|
2024-04-30 12:52:52 +10:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Paste the drivers from `src_drivers` to the destination property.
|
|
|
|
|
*
|
|
|
|
|
* This function can be used for pasting drivers for all elements of an array
|
|
|
|
|
* property, just some elements of an array property, or a single driver for a
|
|
|
|
|
* non-array property.
|
|
|
|
|
*
|
2024-05-03 11:32:43 +10:00
|
|
|
* \note intended to be used in conjunction with `get_property_drivers()` above.
|
2024-04-30 12:52:52 +10:00
|
|
|
* The destination property should have the same type and (if an array property)
|
|
|
|
|
* length as the source property passed to `get_property_drivers()`.
|
|
|
|
|
*
|
|
|
|
|
* \param src_drivers: The span of drivers to paste. If `is_array_prop` is
|
|
|
|
|
* false, this must be a single element. If `is_array_prop` is true then this
|
2024-07-14 18:55:43 +10:00
|
|
|
* should have the same length as the destination array property. Nullptr
|
2024-04-30 12:52:52 +10:00
|
|
|
* elements are skipped when pasting.
|
|
|
|
|
* \param is_array_prop: Whether `src_drivers` are drivers for the elements
|
|
|
|
|
* of an array property.
|
|
|
|
|
* \param dst_ptr: The RNA pointer for the destination property.
|
|
|
|
|
* \param dist_prop: The destination property RNA.
|
|
|
|
|
*
|
|
|
|
|
* \returns The number of successfully pasted drivers.
|
|
|
|
|
*/
|
2024-04-29 18:34:57 +02:00
|
|
|
int paste_property_drivers(blender::Span<FCurve *> src_drivers,
|
|
|
|
|
bool is_array_prop,
|
|
|
|
|
PointerRNA *dst_ptr,
|
|
|
|
|
PropertyRNA *dst_prop);
|
|
|
|
|
|
|
|
|
|
} // namespace blender::interface::internal
|