2011-02-23 10:52:22 +00: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
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
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
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*/
|
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup edinterface
|
2011-02-27 20:29:51 +00:00
|
|
|
*/
|
|
|
|
|
|
2020-08-07 09:50:34 +02: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
|
|
|
|
2014-01-20 11:13:53 +11:00
|
|
|
#include "BLI_compiler_attrs.h"
|
2020-05-12 12:02:28 +10:00
|
|
|
#include "BLI_rect.h"
|
|
|
|
|
|
2014-11-06 20:19:21 +01:00
|
|
|
#include "DNA_listBase.h"
|
2020-03-06 16:45:06 +01:00
|
|
|
#include "RNA_types.h"
|
|
|
|
|
#include "UI_interface.h"
|
|
|
|
|
#include "UI_resources.h"
|
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
|
|
|
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
struct AnimationEvalContext;
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
struct ARegion;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct ID;
|
|
|
|
|
struct ImBuf;
|
|
|
|
|
struct Scene;
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
struct bContext;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct bContextStore;
|
2008-12-16 07:55:43 +00:00
|
|
|
struct uiHandleButtonData;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiLayout;
|
|
|
|
|
struct uiStyle;
|
2020-05-12 10:55:46 +10:00
|
|
|
struct uiUndoStack_Text;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct uiWidgetColors;
|
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
|
|
|
|
2009-04-07 17:08:26 +00:00
|
|
|
/* ****************** general defines ************** */
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
#define RNA_NO_INDEX -1
|
|
|
|
|
#define RNA_ENUM_VALUE -2
|
2013-11-23 18:43:23 +01:00
|
|
|
|
2019-03-18 17:41:37 +11:00
|
|
|
#define UI_MENU_PADDING (int)(0.2f * UI_UNIT_Y)
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
#define UI_MENU_WIDTH_MIN (UI_UNIT_Y * 9)
|
2019-01-15 23:24:20 +11:00
|
|
|
/* some extra padding added to menus containing submenu icons */
|
|
|
|
|
#define UI_MENU_SUBMENU_PADDING (6 * UI_DPI_FAC)
|
2018-04-25 21:54:29 +02:00
|
|
|
|
2012-10-31 12:56:04 +00:00
|
|
|
/* menu scrolling */
|
2019-04-17 06:17:24 +02:00
|
|
|
#define UI_MENU_SCROLL_ARROW 12
|
|
|
|
|
#define UI_MENU_SCROLL_MOUSE (UI_MENU_SCROLL_ARROW + 2)
|
|
|
|
|
#define UI_MENU_SCROLL_PAD 4
|
2012-10-31 12:56:04 +00: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
|
|
|
/* panel limits */
|
2019-04-17 06:17:24 +02:00
|
|
|
#define UI_PANEL_MINX 100
|
|
|
|
|
#define UI_PANEL_MINY 70
|
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
|
|
|
|
2018-04-22 23:03:08 +02:00
|
|
|
/* popover width (multiplied by 'U.widget_unit') */
|
|
|
|
|
#define UI_POPOVER_WIDTH_UNITS 10
|
|
|
|
|
|
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
|
|
|
/* uiBut->flag */
|
2013-11-21 14:43:08 +01:00
|
|
|
enum {
|
2019-04-17 06:17:24 +02:00
|
|
|
UI_SELECT = (1 << 0), /* use when the button is pressed */
|
|
|
|
|
UI_SCROLLED = (1 << 1), /* temp hidden, scrolled away */
|
|
|
|
|
UI_ACTIVE = (1 << 2),
|
|
|
|
|
UI_HAS_ICON = (1 << 3),
|
|
|
|
|
UI_HIDDEN = (1 << 4),
|
|
|
|
|
UI_SELECT_DRAW = (1 << 5), /* Display selected, doesn't impact interaction. */
|
|
|
|
|
/* warn: rest of uiBut->flag in UI_interface.h */
|
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
|
|
|
|
2015-08-10 18:01:11 +02:00
|
|
|
/* uiBut->dragflag */
|
|
|
|
|
enum {
|
2019-04-17 06:17:24 +02:00
|
|
|
UI_BUT_DRAGPOIN_FREE = (1 << 0),
|
2015-08-10 18:01:11 +02: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
|
|
|
/* but->pie_dir */
|
|
|
|
|
typedef enum RadialDirection {
|
2019-04-17 06:17:24 +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,
|
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
|
|
|
} RadialDirection;
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
extern const char ui_radial_dir_order[8];
|
|
|
|
|
extern const char ui_radial_dir_to_numpad[8];
|
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 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 */
|
2019-04-17 06:17:24 +02:00
|
|
|
#define PNL_HEADER (UI_UNIT_Y * 1.2) /* 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-04-17 06:17:24 +02: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)))
|
2019-03-25 16:17:39 +11:00
|
|
|
|
2012-09-03 10:12:25 +00:00
|
|
|
/* bit-row */
|
2019-04-17 06:17:24 +02: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
|
|
|
|
2013-12-11 21:27:13 +11:00
|
|
|
/* split numbuts by ':' and align l/r */
|
|
|
|
|
#define USE_NUMBUTS_LR_ALIGN
|
|
|
|
|
|
2015-11-06 18:39:56 +01:00
|
|
|
/* Use new 'align' computation code. */
|
|
|
|
|
#define USE_UIBUT_SPATIAL_ALIGN
|
|
|
|
|
|
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
|
|
|
/* PieMenuData->flags */
|
|
|
|
|
enum {
|
2019-04-17 06:17:24 +02:00
|
|
|
/** pie menu item collision is detected at 90 degrees */
|
|
|
|
|
UI_PIE_DEGREES_RANGE_LARGE = (1 << 0),
|
|
|
|
|
/** use initial center of pie menu to calculate direction */
|
|
|
|
|
UI_PIE_INITIAL_DIRECTION = (1 << 1),
|
|
|
|
|
/** pie menu is drag style */
|
|
|
|
|
UI_PIE_DRAG_STYLE = (1 << 2),
|
|
|
|
|
/** mouse not far enough from center position */
|
|
|
|
|
UI_PIE_INVALID_DIR = (1 << 3),
|
|
|
|
|
/** pie menu changed to click style, click to confirm */
|
|
|
|
|
UI_PIE_CLICK_STYLE = (1 << 4),
|
|
|
|
|
/** pie animation finished, do not calculate any more motion */
|
|
|
|
|
UI_PIE_ANIMATION_FINISHED = (1 << 5),
|
|
|
|
|
/** pie gesture selection has been done, now wait for mouse motion to end */
|
|
|
|
|
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
|
|
|
|
|
|
2016-02-16 14:50:26 +01:00
|
|
|
/* max amount of items a radial menu (pie menu) can contain */
|
|
|
|
|
#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 {
|
2019-04-17 06:17:24 +02:00
|
|
|
struct uiBut *next, *prev;
|
2020-05-02 02:06:16 +02:00
|
|
|
|
|
|
|
|
/* Pointer back to the layout item holding this button. */
|
|
|
|
|
uiLayout *layout;
|
2019-04-17 06:17:24 +02:00
|
|
|
int flag, drawflag;
|
|
|
|
|
eButType type;
|
|
|
|
|
eButPointerType pointype;
|
|
|
|
|
short bit, bitnr, retval, strwidth, alignnr;
|
|
|
|
|
short ofs, pos, selsta, selend;
|
|
|
|
|
|
|
|
|
|
char *str;
|
|
|
|
|
char strdata[UI_MAX_NAME_STR];
|
|
|
|
|
char drawstr[UI_MAX_DRAW_STR];
|
|
|
|
|
|
|
|
|
|
rctf rect; /* block relative coords */
|
|
|
|
|
|
|
|
|
|
char *poin;
|
|
|
|
|
float hardmin, hardmax, softmin, softmax;
|
|
|
|
|
|
|
|
|
|
/* both these values use depends on the button type
|
|
|
|
|
* (polymorphic struct or union would be nicer for this stuff) */
|
|
|
|
|
|
2019-04-17 08:44:38 +02:00
|
|
|
/**
|
|
|
|
|
* For #uiBut.type:
|
|
|
|
|
* - UI_BTYPE_HSVCUBE: Use UI_GRAD_* values.
|
|
|
|
|
* - UI_BTYPE_NUM: Use to store RNA 'step' value, for dragging and click-step.
|
|
|
|
|
* - UI_BTYPE_LABEL: Use `(a1 == 1.0f)` to use a2 as a blending factor (imaginative!).
|
|
|
|
|
* - UI_BTYPE_SCROLL: Use as scroll size.
|
|
|
|
|
* - UI_BTYPE_SEARCH_MENU: Use as number or rows.
|
2019-04-17 06:17:24 +02:00
|
|
|
*/
|
|
|
|
|
float a1;
|
|
|
|
|
|
2019-04-17 08:44:38 +02:00
|
|
|
/**
|
|
|
|
|
* For #uiBut.type:
|
|
|
|
|
* - UI_BTYPE_HSVCIRCLE: Use to store the luminosity.
|
|
|
|
|
* - UI_BTYPE_NUM: Use to store RNA 'precision' value, for dragging and click-step.
|
|
|
|
|
* - UI_BTYPE_LABEL: If `(a1 == 1.0f)` use a2 as a blending factor.
|
|
|
|
|
* - UI_BTYPE_SEARCH_MENU: Use as number or columns.
|
2019-04-17 06:17:24 +02:00
|
|
|
*/
|
|
|
|
|
float a2;
|
|
|
|
|
|
|
|
|
|
uchar col[4];
|
|
|
|
|
|
|
|
|
|
uiButHandleFunc func;
|
|
|
|
|
void *func_arg1;
|
|
|
|
|
void *func_arg2;
|
|
|
|
|
|
|
|
|
|
uiButHandleNFunc funcN;
|
|
|
|
|
void *func_argN;
|
|
|
|
|
|
|
|
|
|
struct bContextStore *context;
|
|
|
|
|
|
|
|
|
|
uiButCompleteFunc autocomplete_func;
|
|
|
|
|
void *autofunc_arg;
|
|
|
|
|
|
|
|
|
|
uiButHandleRenameFunc rename_func;
|
|
|
|
|
void *rename_arg1;
|
|
|
|
|
void *rename_orig;
|
|
|
|
|
|
|
|
|
|
/** Run an action when holding the button down. */
|
|
|
|
|
uiButHandleHoldFunc hold_func;
|
|
|
|
|
void *hold_argN;
|
|
|
|
|
|
|
|
|
|
const char *tip;
|
|
|
|
|
uiButToolTipFunc tip_func;
|
|
|
|
|
void *tip_argN;
|
|
|
|
|
|
|
|
|
|
/** info on why button is disabled, displayed in tooltip */
|
|
|
|
|
const char *disabled_info;
|
|
|
|
|
|
|
|
|
|
BIFIconID icon;
|
2020-07-29 12:05:27 +10:00
|
|
|
/** emboss: UI_EMBOSS, UI_EMBOSS_NONE ... etc, copied from the #uiBlock.emboss */
|
|
|
|
|
char emboss;
|
2019-04-17 06:17:24 +02:00
|
|
|
/** direction in a pie menu, used for collision detection (RadialDirection) */
|
|
|
|
|
signed char pie_dir;
|
|
|
|
|
/** could be made into a single flag */
|
|
|
|
|
bool changed;
|
|
|
|
|
/** so buttons can support unit systems which are not RNA */
|
|
|
|
|
uchar unit_type;
|
|
|
|
|
short modifier_key;
|
|
|
|
|
short iconadd;
|
|
|
|
|
|
|
|
|
|
/* UI_BTYPE_BLOCK data */
|
|
|
|
|
uiBlockCreateFunc block_create_func;
|
|
|
|
|
|
|
|
|
|
/* UI_BTYPE_PULLDOWN/UI_BTYPE_MENU data */
|
|
|
|
|
uiMenuCreateFunc menu_create_func;
|
|
|
|
|
|
|
|
|
|
uiMenuStepFunc menu_step_func;
|
|
|
|
|
|
|
|
|
|
/* RNA data */
|
|
|
|
|
struct PointerRNA rnapoin;
|
|
|
|
|
struct PropertyRNA *rnaprop;
|
|
|
|
|
int rnaindex;
|
|
|
|
|
|
|
|
|
|
/* Operator data */
|
|
|
|
|
struct wmOperatorType *optype;
|
|
|
|
|
struct PointerRNA *opptr;
|
|
|
|
|
short opcontext;
|
|
|
|
|
uchar menu_key; /* 'a'-'z', always lower case */
|
|
|
|
|
|
2019-09-09 16:34:16 +02:00
|
|
|
ListBase extra_op_icons; /* uiButExtraOpIcon */
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Draggable data, type is WM_DRAG_... */
|
|
|
|
|
char dragtype;
|
|
|
|
|
short dragflag;
|
|
|
|
|
void *dragpoin;
|
|
|
|
|
struct ImBuf *imb;
|
|
|
|
|
float imb_scale;
|
|
|
|
|
|
|
|
|
|
/* active button data */
|
|
|
|
|
struct uiHandleButtonData *active;
|
|
|
|
|
|
|
|
|
|
/* Custom button data. */
|
|
|
|
|
void *custom_data;
|
|
|
|
|
|
|
|
|
|
char *editstr;
|
|
|
|
|
double *editval;
|
|
|
|
|
float *editvec;
|
|
|
|
|
void *editcoba;
|
|
|
|
|
void *editcumap;
|
2019-11-20 16:12:32 -05:00
|
|
|
void *editprofile;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
|
|
|
|
uiButPushedStateFunc pushed_state_func;
|
|
|
|
|
void *pushed_state_arg;
|
|
|
|
|
|
|
|
|
|
/* pointer back */
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
|
2020-07-03 18:47:35 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_COLOR */
|
|
|
|
|
typedef struct uiButColor {
|
|
|
|
|
uiBut but;
|
|
|
|
|
|
|
|
|
|
bool is_pallete_color;
|
|
|
|
|
int palette_color_index;
|
|
|
|
|
} uiButColor;
|
|
|
|
|
|
2020-05-02 02:06:16 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_TAB */
|
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
|
|
|
typedef struct uiButTab {
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut but;
|
|
|
|
|
struct MenuType *menu;
|
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
|
|
|
} uiButTab;
|
|
|
|
|
|
2020-05-02 02:06:16 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_SEARCH_MENU */
|
|
|
|
|
typedef struct uiButSearch {
|
|
|
|
|
uiBut but;
|
|
|
|
|
|
2020-06-05 14:18:46 +02:00
|
|
|
uiButSearchCreateFn popup_create_fn;
|
|
|
|
|
uiButSearchUpdateFn items_update_fn;
|
2020-06-07 21:38:12 +02:00
|
|
|
void *item_active;
|
2020-06-05 14:18:46 +02:00
|
|
|
|
|
|
|
|
void *arg;
|
|
|
|
|
uiButSearchArgFreeFn arg_free_fn;
|
|
|
|
|
|
|
|
|
|
uiButSearchContextMenuFn item_context_menu_fn;
|
|
|
|
|
uiButSearchTooltipFn item_tooltip_fn;
|
2020-05-02 02:06:16 +02:00
|
|
|
|
|
|
|
|
const char *item_sep_string;
|
|
|
|
|
|
|
|
|
|
struct PointerRNA rnasearchpoin;
|
|
|
|
|
struct PropertyRNA *rnasearchprop;
|
|
|
|
|
} uiButSearch;
|
|
|
|
|
|
2020-05-03 21:03:22 +02:00
|
|
|
/** Derived struct for #UI_BTYPE_DECORATOR */
|
|
|
|
|
typedef struct uiButDecorator {
|
|
|
|
|
uiBut but;
|
|
|
|
|
|
|
|
|
|
struct PointerRNA rnapoin;
|
|
|
|
|
struct PropertyRNA *rnaprop;
|
|
|
|
|
int rnaindex;
|
|
|
|
|
} uiButDecorator;
|
|
|
|
|
|
2020-07-03 16:31:29 +02:00
|
|
|
typedef struct uiButProgressbar {
|
|
|
|
|
uiBut but;
|
|
|
|
|
|
|
|
|
|
/* 0..1 range */
|
|
|
|
|
float progress;
|
|
|
|
|
} uiButProgressbar;
|
|
|
|
|
|
2019-09-09 16:34:16 +02:00
|
|
|
/**
|
|
|
|
|
* Additional, superimposed icon for a button, invoking an operator.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct uiButExtraOpIcon {
|
|
|
|
|
struct uiButExtraOpIcon *next, *prev;
|
|
|
|
|
|
|
|
|
|
BIFIconID icon;
|
|
|
|
|
struct wmOperatorCallParams *optype_params;
|
|
|
|
|
} uiButExtraOpIcon;
|
|
|
|
|
|
2014-11-06 20:19:21 +01:00
|
|
|
typedef struct ColorPicker {
|
2019-04-17 06:17:24 +02:00
|
|
|
struct ColorPicker *next, *prev;
|
|
|
|
|
/** Color data, may be HSV or HSL. */
|
|
|
|
|
float color_data[3];
|
|
|
|
|
/** Initial color data (detect changes). */
|
|
|
|
|
float color_data_init[3];
|
|
|
|
|
bool is_init;
|
|
|
|
|
/** Cubic saturation for the color wheel. */
|
|
|
|
|
bool use_color_cubic;
|
|
|
|
|
bool use_color_lock;
|
|
|
|
|
bool use_luminosity_lock;
|
|
|
|
|
float luminosity_lock_value;
|
2014-11-06 20:19:21 +01:00
|
|
|
} ColorPicker;
|
|
|
|
|
|
|
|
|
|
typedef struct ColorPickerData {
|
2019-04-17 06:17:24 +02:00
|
|
|
ListBase list;
|
2014-11-06 20:19:21 +01:00
|
|
|
} ColorPickerData;
|
|
|
|
|
|
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-04-17 06:17:24 +02:00
|
|
|
/** store title and icon to allow access when pie levels are created */
|
|
|
|
|
const char *title;
|
|
|
|
|
int icon;
|
|
|
|
|
|
|
|
|
|
float pie_dir[2];
|
|
|
|
|
float pie_center_init[2];
|
|
|
|
|
float pie_center_spawned[2];
|
|
|
|
|
float last_pos[2];
|
|
|
|
|
double duration_gesture;
|
|
|
|
|
int flags;
|
|
|
|
|
/** initial event used to fire the pie menu, store here so we can query for release */
|
|
|
|
|
int event;
|
|
|
|
|
float alphafac;
|
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
|
|
|
};
|
|
|
|
|
|
2018-07-06 19:26:12 +02:00
|
|
|
/* uiBlock.content_hints */
|
|
|
|
|
enum eBlockContentHints {
|
2019-04-17 06:17:24 +02:00
|
|
|
/** In a menu block, if there is a single sub-menu button, we add some
|
|
|
|
|
* padding to the right to put nicely aligned triangle icons there. */
|
|
|
|
|
UI_BLOCK_CONTAINS_SUBMENU_BUT = (1 << 0),
|
2018-07-06 19:26: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
|
|
|
struct uiBlock {
|
2019-04-17 06:17:24 +02:00
|
|
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
ListBase buttons;
|
2020-05-12 12:02:28 +10:00
|
|
|
struct Panel *panel;
|
2019-04-17 06:17:24 +02: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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
ListBase butstore; /* UI_butstore_* runtime function */
|
2014-02-08 09:03:25 +11:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
ListBase layouts;
|
|
|
|
|
struct uiLayout *curlayout;
|
2009-05-28 23:13:42 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
ListBase contexts;
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
char name[UI_MAX_NAME_STR];
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
float winmat[4][4];
|
2012-08-18 16:53:46 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
rctf rect;
|
|
|
|
|
float aspect;
|
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-04-17 06:17:24 +02:00
|
|
|
uint puphash; /* popup menu hash for memory */
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
uiButHandleFunc func;
|
|
|
|
|
void *func_arg1;
|
|
|
|
|
void *func_arg2;
|
2008-12-10 19:22:10 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
uiButHandleNFunc funcN;
|
|
|
|
|
void *func_argN;
|
2009-09-16 18:47:42 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
uiMenuHandleFunc butm_func;
|
|
|
|
|
void *butm_func_arg;
|
2008-12-10 19:22:10 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBlockHandleFunc handle_func;
|
|
|
|
|
void *handle_func_arg;
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* custom extra handling */
|
|
|
|
|
int (*block_event_func)(const struct bContext *C, struct uiBlock *, const struct wmEvent *);
|
2018-05-23 10:47:12 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* extra draw function for custom blocks */
|
|
|
|
|
void (*drawextra)(const struct bContext *C, void *idv, void *arg1, void *arg2, rcti *rect);
|
|
|
|
|
void *drawextra_arg1;
|
|
|
|
|
void *drawextra_arg2;
|
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-04-17 06:17:24 +02:00
|
|
|
int flag;
|
|
|
|
|
short alignnr;
|
|
|
|
|
/** Hints about the buttons of this block. Used to avoid iterating over
|
|
|
|
|
* 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. */
|
|
|
|
|
short content_hints; /* eBlockContentHints */
|
2011-10-03 01:36:25 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
char direction;
|
|
|
|
|
/** UI_BLOCK_THEME_STYLE_* */
|
|
|
|
|
char theme_style;
|
2020-07-29 12:05:27 +10:00
|
|
|
/** UI_EMBOSS, UI_EMBOSS_NONE ... etc, copied to #uiBut.emboss */
|
|
|
|
|
char emboss;
|
2019-04-17 06:17:24 +02:00
|
|
|
bool auto_open;
|
|
|
|
|
char _pad[5];
|
|
|
|
|
double auto_open_last;
|
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-04-17 06:17:24 +02:00
|
|
|
const char *lockstr;
|
2010-10-14 11:33:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
char lock;
|
|
|
|
|
/** to keep blocks while drawing and free them afterwards */
|
|
|
|
|
char active;
|
|
|
|
|
/** to avoid tooltip after click */
|
|
|
|
|
char tooltipdisabled;
|
|
|
|
|
/** UI_block_end done? */
|
|
|
|
|
char endblock;
|
2019-01-15 23:24:20 +11:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** for doing delayed */
|
|
|
|
|
eBlockBoundsCalc bounds_type;
|
|
|
|
|
/** Offset to use when calculating bounds (in pixels). */
|
|
|
|
|
int bounds_offset[2];
|
|
|
|
|
/** 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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** pulldowns, to detect outside, can differ per case how it is created */
|
|
|
|
|
rctf safety;
|
|
|
|
|
/** uiSafetyRct list */
|
|
|
|
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
uiPopupBlockHandle *handle; /* handle */
|
2011-11-10 03:44:50 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** use so presets can find the operator,
|
|
|
|
|
* across menus and from nested popups which fail for operator context. */
|
|
|
|
|
struct wmOperator *ui_operator;
|
2011-11-10 03:44:50 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** XXX hack for dynamic operator enums */
|
|
|
|
|
void *evil_C;
|
2010-10-14 11:33:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** unit system, used a lot for numeric buttons so include here
|
|
|
|
|
* rather then fetching through the scene every time. */
|
|
|
|
|
struct UnitSettings *unit;
|
|
|
|
|
/** \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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
bool is_color_gamma_picker; /* Block for color picker with gamma baked in. */
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/** display device name used to display this block,
|
|
|
|
|
* used by color widgets to transform colors from/to scene linear
|
|
|
|
|
*/
|
|
|
|
|
char display_device[64];
|
2019-01-15 23:24:20 +11:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
struct PieMenuData pie_data;
|
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
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct uiSafetyRct {
|
2019-04-17 06:17:24 +02:00
|
|
|
struct uiSafetyRct *next, *prev;
|
|
|
|
|
rctf parent;
|
|
|
|
|
rctf safety;
|
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
|
|
|
} uiSafetyRct;
|
|
|
|
|
|
|
|
|
|
/* interface.c */
|
|
|
|
|
|
2009-04-15 14:43:54 +00:00
|
|
|
void ui_fontscale(short *points, float aspect);
|
|
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
extern void ui_block_to_window_fl(const struct ARegion *region,
|
|
|
|
|
uiBlock *block,
|
|
|
|
|
float *x,
|
|
|
|
|
float *y);
|
|
|
|
|
extern void ui_block_to_window(const struct ARegion *region, uiBlock *block, int *x, int *y);
|
|
|
|
|
extern void ui_block_to_window_rctf(const struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBlock *block,
|
|
|
|
|
rctf *rct_dst,
|
|
|
|
|
const rctf *rct_src);
|
2020-03-06 16:56:42 +01:00
|
|
|
extern float ui_block_to_window_scale(const struct ARegion *region, uiBlock *block);
|
|
|
|
|
extern void ui_window_to_block_fl(const struct ARegion *region,
|
|
|
|
|
uiBlock *block,
|
|
|
|
|
float *x,
|
|
|
|
|
float *y);
|
|
|
|
|
extern void ui_window_to_block(const struct ARegion *region, uiBlock *block, int *x, int *y);
|
|
|
|
|
extern void ui_window_to_block_rctf(const struct ARegion *region,
|
2019-04-23 16:39:14 +10:00
|
|
|
uiBlock *block,
|
|
|
|
|
rctf *rct_dst,
|
|
|
|
|
const rctf *rct_src);
|
2020-05-12 12:02:28 +10:00
|
|
|
extern void ui_window_to_region(const struct ARegion *region, int *x, int *y);
|
|
|
|
|
extern void ui_window_to_region_rcti(const struct ARegion *region,
|
|
|
|
|
rcti *rect_dst,
|
|
|
|
|
const rcti *rct_src);
|
2020-03-06 16:56:42 +01:00
|
|
|
extern void ui_region_to_window(const struct ARegion *region, int *x, int *y);
|
|
|
|
|
extern void ui_region_winrct_get_no_margin(const struct ARegion *region, struct 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
|
|
|
|
2020-05-02 02:06:16 +02:00
|
|
|
uiBut *ui_but_change_type(uiBut *but, eButType new_type);
|
|
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
extern double ui_but_value_get(uiBut *but);
|
|
|
|
|
extern void ui_but_value_set(uiBut *but, double value);
|
|
|
|
|
extern void ui_but_hsv_set(uiBut *but);
|
|
|
|
|
extern void ui_but_v3_get(uiBut *but, float vec[3]);
|
|
|
|
|
extern void ui_but_v3_set(uiBut *but, const float vec[3]);
|
2009-03-30 17:31:37 +00:00
|
|
|
|
2015-05-05 03:13:47 +10:00
|
|
|
extern void ui_hsvcircle_vals_from_pos(
|
2019-04-17 06:17:24 +02:00
|
|
|
const rcti *rect, const float mx, const float my, float *r_val_rad, float *r_val_dist);
|
|
|
|
|
extern void ui_hsvcircle_pos_from_vals(
|
|
|
|
|
const ColorPicker *cpicker, const rcti *rect, const float *hsv, float *xpos, float *ypos);
|
|
|
|
|
extern void ui_hsvcube_pos_from_vals(
|
|
|
|
|
const struct uiBut *but, const rcti *rect, const float *hsv, float *xp, float *yp);
|
|
|
|
|
|
|
|
|
|
extern void ui_but_string_get_ex(uiBut *but,
|
|
|
|
|
char *str,
|
|
|
|
|
const size_t maxlen,
|
|
|
|
|
const int float_precision,
|
|
|
|
|
const bool use_exp_float,
|
|
|
|
|
bool *r_use_exp_float) ATTR_NONNULL(1, 2);
|
2014-11-09 21:20:40 +01:00
|
|
|
extern void ui_but_string_get(uiBut *but, char *str, const size_t maxlen) ATTR_NONNULL();
|
2015-11-10 08:35:12 +11:00
|
|
|
extern char *ui_but_string_get_dynamic(uiBut *but, int *r_str_size);
|
2014-11-09 21:20:40 +01:00
|
|
|
extern void ui_but_convert_to_unit_alt_name(uiBut *but, char *str, size_t maxlen) ATTR_NONNULL();
|
|
|
|
|
extern bool ui_but_string_set(struct bContext *C, uiBut *but, const char *str) ATTR_NONNULL();
|
2020-07-27 12:03:02 +10:00
|
|
|
extern bool ui_but_string_eval_number(struct bContext *C,
|
|
|
|
|
const uiBut *but,
|
|
|
|
|
const char *str,
|
|
|
|
|
double *value) ATTR_NONNULL();
|
2019-04-17 06:17:24 +02:00
|
|
|
extern int ui_but_string_get_max_length(uiBut *but);
|
2019-09-09 16:34:16 +02:00
|
|
|
/* Clear & exit the active button's string. */
|
|
|
|
|
extern void ui_but_active_string_clear_and_exit(struct bContext *C, uiBut *but) ATTR_NONNULL();
|
2014-11-09 21:20:40 +01:00
|
|
|
extern uiBut *ui_but_drag_multi_edit_get(uiBut *but);
|
2015-05-11 16:29:12 +02:00
|
|
|
|
|
|
|
|
void ui_def_but_icon(uiBut *but, const int icon, const int flag);
|
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
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
extern void ui_but_default_set(struct bContext *C, const bool all, const bool use_afterfunc);
|
2010-01-20 04:19:55 +00:00
|
|
|
|
2019-09-09 16:34:16 +02:00
|
|
|
void ui_but_extra_operator_icons_free(uiBut *but);
|
|
|
|
|
|
2019-03-25 20:10:32 +11:00
|
|
|
extern void ui_but_rna_menu_convert_to_panel_type(struct uiBut *but, const char *panel_type);
|
2019-03-25 20:31:06 +11:00
|
|
|
extern void ui_but_rna_menu_convert_to_menu_type(struct uiBut *but, const char *menu_type);
|
2019-03-25 18:55:38 +11:00
|
|
|
extern bool ui_but_menu_draw_as_popover(const uiBut *but);
|
|
|
|
|
|
2020-07-09 15:38:31 +02:00
|
|
|
void ui_but_range_set_hard(uiBut *but);
|
|
|
|
|
void ui_but_range_set_soft(uiBut *but);
|
|
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
extern void ui_but_update(uiBut *but);
|
2016-02-23 09:55:16 +11:00
|
|
|
extern void ui_but_update_edited(uiBut *but);
|
2014-11-09 21:20:40 +01:00
|
|
|
extern bool ui_but_is_float(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
extern bool ui_but_is_bool(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
extern bool ui_but_is_unit(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
extern bool ui_but_is_compatible(const uiBut *but_a, const uiBut *but_b) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
extern bool ui_but_is_rna_valid(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2015-09-05 19:28:24 +02:00
|
|
|
extern 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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
extern int ui_but_is_pushed_ex(uiBut *but, double *value) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
extern int ui_but_is_pushed(uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2013-03-01 00:19:32 +00:00
|
|
|
|
2020-07-16 11:03:11 +02:00
|
|
|
void ui_but_override_flag(struct Main *bmain, uiBut *but);
|
2013-03-01 00:19:32 +00:00
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
extern 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
|
|
|
|
2014-11-09 21:20:40 +01:00
|
|
|
extern struct ColorManagedDisplay *ui_block_cm_display_get(uiBlock *block);
|
|
|
|
|
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
|
|
|
|
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
|
|
|
/* interface_regions.c */
|
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 {
|
2019-04-17 06:17:24 +02:00
|
|
|
/* set when we're using keyinput */
|
|
|
|
|
bool is_keynav;
|
|
|
|
|
/* only used to check if we've moved the cursor */
|
|
|
|
|
int event_xy[2];
|
2013-04-11 02:28:34 +00:00
|
|
|
};
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
typedef uiBlock *(*uiBlockHandleCreateFunc)(struct bContext *C,
|
|
|
|
|
struct uiPopupBlockHandle *handle,
|
|
|
|
|
void *arg1);
|
2014-06-15 01:40:15 +10:00
|
|
|
|
|
|
|
|
struct uiPopupBlockCreate {
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBlockCreateFunc create_func;
|
|
|
|
|
uiBlockHandleCreateFunc handle_create_func;
|
|
|
|
|
void *arg;
|
2019-05-14 15:38:51 +02:00
|
|
|
void (*arg_free)(void *arg);
|
2014-06-15 01:40:15 +10:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
int event_xy[2];
|
2014-06-15 01:40:15 +10:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* when popup is initialized from a button */
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *butregion;
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but;
|
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 {
|
2019-04-17 06:17:24 +02:00
|
|
|
/* internal */
|
|
|
|
|
struct ARegion *region;
|
|
|
|
|
|
|
|
|
|
/* use only for 'UI_BLOCK_MOVEMOUSE_QUIT' popups */
|
|
|
|
|
float towards_xy[2];
|
|
|
|
|
double towardstime;
|
|
|
|
|
bool dotowards;
|
|
|
|
|
|
|
|
|
|
bool popup;
|
|
|
|
|
void (*popup_func)(struct bContext *C, void *arg, int event);
|
|
|
|
|
void (*cancel_func)(struct bContext *C, void *arg);
|
|
|
|
|
void *popup_arg;
|
|
|
|
|
|
|
|
|
|
/* store data for refreshing popups */
|
|
|
|
|
struct uiPopupBlockCreate popup_create_vars;
|
|
|
|
|
/* true if we can re-create the popup using 'popup_create_vars' */
|
|
|
|
|
bool can_refresh;
|
|
|
|
|
bool refresh;
|
|
|
|
|
|
|
|
|
|
struct wmTimer *scrolltimer;
|
|
|
|
|
float scrolloffset;
|
|
|
|
|
|
|
|
|
|
struct uiKeyNavLock keynav_state;
|
|
|
|
|
|
|
|
|
|
/* for operator popups */
|
|
|
|
|
struct wmOperator *popup_op;
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ScrArea *ctx_area;
|
|
|
|
|
struct ARegion *ctx_region;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
|
|
|
|
/* return values */
|
|
|
|
|
int butretval;
|
|
|
|
|
int menuretval;
|
|
|
|
|
int retvalue;
|
|
|
|
|
float retvec[4];
|
|
|
|
|
|
|
|
|
|
/* menu direction */
|
|
|
|
|
int direction;
|
|
|
|
|
|
|
|
|
|
/* Previous values so we don't resize or reposition on refresh. */
|
|
|
|
|
rctf prev_block_rect;
|
|
|
|
|
rctf prev_butrct;
|
|
|
|
|
short prev_dir1, prev_dir2;
|
|
|
|
|
int prev_bounds_offset[2];
|
|
|
|
|
|
|
|
|
|
/* Maximum estimated size to avoid having to reposition on refresh. */
|
|
|
|
|
float max_size_x, max_size_y;
|
|
|
|
|
|
|
|
|
|
/* #ifdef USE_DRAG_POPUP */
|
|
|
|
|
bool is_grab;
|
|
|
|
|
int grab_xy_prev[2];
|
|
|
|
|
/* #endif */
|
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
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/* interface_region_*.c */
|
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
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* interface_region_tooltip.c */
|
2017-12-20 14:50:39 +11:00
|
|
|
/* exposed as public API in UI_interface.h */
|
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
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* interface_region_color_picker.c */
|
2014-03-12 18:58:50 +02:00
|
|
|
void ui_rgb_to_color_picker_compat_v(const float rgb[3], float r_cp[3]);
|
2014-04-12 19:27:16 +03:00
|
|
|
void ui_rgb_to_color_picker_v(const float rgb[3], float r_cp[3]);
|
2014-03-12 18:58:50 +02:00
|
|
|
void ui_color_picker_to_rgb_v(const float r_cp[3], float rgb[3]);
|
|
|
|
|
void ui_color_picker_to_rgb(float r_cp0, float r_cp1, float r_cp2, float *r, float *g, float *b);
|
2010-10-13 13:53:49 +00:00
|
|
|
|
2018-12-13 15:59:58 +01:00
|
|
|
bool ui_but_is_color_gamma(uiBut *but);
|
|
|
|
|
|
|
|
|
|
void ui_scene_linear_to_color_picker_space(uiBut *but, float rgb[3]);
|
|
|
|
|
void ui_color_picker_to_scene_linear_space(uiBut *but, float rgb[3]);
|
|
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
uiBlock *ui_block_func_COLOR(struct bContext *C, uiPopupBlockHandle *handle, void *arg_but);
|
|
|
|
|
ColorPicker *ui_block_colorpicker_create(struct uiBlock *block);
|
|
|
|
|
|
|
|
|
|
/* interface_region_search.c */
|
|
|
|
|
/* Searchbox for string button */
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *ui_searchbox_create_generic(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
2020-06-05 13:53:47 +02:00
|
|
|
uiButSearch *search_but);
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *ui_searchbox_create_operator(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
2020-06-05 13:53:47 +02:00
|
|
|
uiButSearch *search_but);
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *ui_searchbox_create_menu(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
2020-06-05 13:53:47 +02:00
|
|
|
uiButSearch *search_but);
|
2020-03-24 11:34:18 +11:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
bool ui_searchbox_inside(struct ARegion *region, int x, int y);
|
|
|
|
|
int ui_searchbox_find_index(struct ARegion *region, const char *name);
|
|
|
|
|
void ui_searchbox_update(struct bContext *C, struct ARegion *region, uiBut *but, const bool reset);
|
|
|
|
|
int ui_searchbox_autocomplete(struct bContext *C, struct ARegion *region, uiBut *but, char *str);
|
2020-05-07 23:16:22 +10:00
|
|
|
bool ui_searchbox_event(struct bContext *C,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
2020-05-11 18:37:43 +10:00
|
|
|
struct ARegion *butregion,
|
2019-04-17 06:17:24 +02:00
|
|
|
const struct wmEvent *event);
|
2020-03-06 16:56:42 +01:00
|
|
|
bool ui_searchbox_apply(uiBut *but, struct ARegion *region);
|
|
|
|
|
void ui_searchbox_free(struct bContext *C, struct ARegion *region);
|
2020-05-02 02:06:16 +02:00
|
|
|
void ui_but_search_refresh(uiButSearch *but);
|
2009-06-02 18:10:06 +00:00
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* interface_region_menu_popup.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
int ui_but_menu_step(uiBut *but, int step);
|
|
|
|
|
bool ui_but_menu_step_poll(const uiBut *but);
|
2017-11-03 20:26:35 +11:00
|
|
|
uiBut *ui_popup_menu_memory_get(struct uiBlock *block);
|
2019-04-17 06:17:24 +02:00
|
|
|
void ui_popup_menu_memory_set(uiBlock *block, struct uiBut *but);
|
|
|
|
|
|
|
|
|
|
uiBlock *ui_popup_block_refresh(struct bContext *C,
|
|
|
|
|
uiPopupBlockHandle *handle,
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *butregion,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but);
|
|
|
|
|
|
|
|
|
|
uiPopupBlockHandle *ui_popup_block_create(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
|
|
|
|
uiBut *but,
|
|
|
|
|
uiBlockCreateFunc create_func,
|
|
|
|
|
uiBlockHandleCreateFunc handle_create_func,
|
2019-05-14 15:38:51 +02:00
|
|
|
void *arg,
|
|
|
|
|
void (*arg_free)(void *arg));
|
2019-04-17 06:17:24 +02:00
|
|
|
uiPopupBlockHandle *ui_popup_menu_create(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
|
|
|
|
uiBut *but,
|
|
|
|
|
uiMenuCreateFunc create_func,
|
|
|
|
|
void *arg);
|
2009-08-21 02:51:56 +00:00
|
|
|
|
2018-04-22 17:16:39 +02:00
|
|
|
/* interface_region_popover.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
uiPopupBlockHandle *ui_popover_panel_create(struct bContext *C,
|
|
|
|
|
struct ARegion *butregion,
|
|
|
|
|
uiBut *but,
|
|
|
|
|
uiMenuCreateFunc create_func,
|
|
|
|
|
void *arg);
|
2018-04-22 17:16:39 +02:00
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* interface_region_menu_pie.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
void ui_pie_menu_level_create(uiBlock *block,
|
|
|
|
|
struct wmOperatorType *ot,
|
|
|
|
|
const char *propname,
|
2020-05-12 12:53:48 +10:00
|
|
|
struct IDProperty *properties,
|
2019-04-17 06:17:24 +02:00
|
|
|
const EnumPropertyItem *items,
|
|
|
|
|
int totitem,
|
|
|
|
|
int context,
|
|
|
|
|
int flag);
|
2016-02-16 14:50:26 +01:00
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* interface_region_popup.c */
|
2020-03-06 16:56:42 +01:00
|
|
|
void ui_popup_translate(struct ARegion *region, const int mdiff[2]);
|
2.5: UI & Menus
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
2009-01-30 12:18:08 +00:00
|
|
|
void ui_popup_block_free(struct bContext *C, uiPopupBlockHandle *handle);
|
2017-11-03 20:26:35 +11:00
|
|
|
void ui_popup_block_scrolltest(struct 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
|
|
|
|
2017-11-03 20:26:35 +11:00
|
|
|
/* end interface_region_*.c */
|
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
|
|
|
|
|
|
|
|
/* interface_panel.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
extern int ui_handler_panel_region(struct bContext *C,
|
|
|
|
|
const struct wmEvent *event,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
const uiBut *active_but);
|
|
|
|
|
extern void ui_draw_aligned_panel(struct uiStyle *style,
|
|
|
|
|
uiBlock *block,
|
|
|
|
|
const rcti *rect,
|
|
|
|
|
const bool show_pin,
|
|
|
|
|
const bool show_background);
|
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
|
|
|
|
|
|
|
|
/* interface_draw.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
extern void ui_draw_dropshadow(
|
|
|
|
|
const rctf *rct, float radius, float aspect, float alpha, int select);
|
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-12-13 02:40:49 +00:00
|
|
|
void ui_draw_gradient(const rcti *rect, const float hsv[3], const int type, const float alpha);
|
2010-01-21 00:00:45 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void ui_draw_but_TAB_outline(const rcti *rect,
|
|
|
|
|
float rad,
|
|
|
|
|
uchar highlight[3],
|
|
|
|
|
uchar highlight_fade[3]);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_HISTOGRAM(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_WAVEFORM(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_VECTORSCOPE(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2019-01-04 09:58:03 +11:00
|
|
|
void ui_draw_but_COLORBAND(uiBut *but, const struct uiWidgetColors *wcol, const rcti *rect);
|
|
|
|
|
void ui_draw_but_UNITVEC(uiBut *but, const struct uiWidgetColors *wcol, const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_CURVE(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_CURVEPROFILE(struct ARegion *region,
|
2019-11-20 16:12:32 -05:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_IMAGE(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_but_TRACKPREVIEW(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
const struct uiWidgetColors *wcol,
|
|
|
|
|
const rcti *rect);
|
2009-04-06 15:44:30 +00:00
|
|
|
|
2020-05-12 10:55:46 +10:00
|
|
|
/* interface_undo.c */
|
|
|
|
|
struct uiUndoStack_Text *ui_textedit_undo_stack_create(void);
|
|
|
|
|
void ui_textedit_undo_stack_destroy(struct uiUndoStack_Text *undo_stack);
|
|
|
|
|
void ui_textedit_undo_push(struct uiUndoStack_Text *undo_stack,
|
|
|
|
|
const char *text,
|
|
|
|
|
int cursor_index);
|
|
|
|
|
const char *ui_textedit_undo(struct uiUndoStack_Text *undo_stack,
|
|
|
|
|
int direction,
|
|
|
|
|
int *r_cursor_index);
|
|
|
|
|
|
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
|
|
|
/* interface_handlers.c */
|
2019-04-17 06:17:24 +02:00
|
|
|
PointerRNA *ui_handle_afterfunc_add_operator(struct wmOperatorType *ot,
|
|
|
|
|
int opcontext,
|
|
|
|
|
bool create_props);
|
2013-02-01 01:01:20 +00:00
|
|
|
extern void ui_pan_to_scroll(const struct wmEvent *event, int *type, int *val);
|
2020-03-06 16:56:42 +01:00
|
|
|
extern void ui_but_activate_event(struct bContext *C, struct ARegion *region, uiBut *but);
|
|
|
|
|
extern void ui_but_activate_over(struct bContext *C, struct ARegion *region, uiBut *but);
|
2019-04-17 06:17:24 +02:00
|
|
|
extern void ui_but_execute_begin(struct bContext *C,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
void **active_back);
|
|
|
|
|
extern void ui_but_execute_end(struct bContext *C,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
uiBut *but,
|
|
|
|
|
void *active_back);
|
2014-11-09 21:20:40 +01:00
|
|
|
extern void ui_but_active_free(const struct bContext *C, uiBut *but);
|
|
|
|
|
extern int ui_but_menu_direction(uiBut *but);
|
2019-04-17 06:17:24 +02:00
|
|
|
extern void ui_but_text_password_hide(char password_str[UI_MAX_DRAW_STR],
|
|
|
|
|
uiBut *but,
|
|
|
|
|
const bool restore);
|
2015-01-21 16:27:21 +11:00
|
|
|
extern 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);
|
2014-11-09 21:20:40 +01:00
|
|
|
float ui_block_calc_pie_segment(struct uiBlock *block, const float event_xy[2]);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
2015-11-07 17:31:28 +11:00
|
|
|
void ui_but_add_shortcut(uiBut *but, const char *key_str, const bool do_strip);
|
2014-11-09 21:20:40 +01:00
|
|
|
void ui_but_clipboard_free(void);
|
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);
|
|
|
|
|
uiBut *ui_but_find_new(uiBlock *block_old, const uiBut *but_new);
|
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);
|
2015-03-26 21:24:01 +01:00
|
|
|
struct wmIMEData *ui_but_ime_data_get(uiBut *but);
|
2014-12-07 00:58:17 +01:00
|
|
|
#endif
|
|
|
|
|
|
2009-04-02 15:01:11 +00:00
|
|
|
/* interface_widgets.c */
|
2018-04-05 18:51:08 +02:00
|
|
|
|
|
|
|
|
/* Widget shader parameters, must match the shader layout. */
|
|
|
|
|
typedef struct uiWidgetBaseParameters {
|
2019-04-17 06:17:24 +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;
|
|
|
|
|
float shade_dir;
|
|
|
|
|
/* We pack alpha check and discard factor in alpha_discard.
|
|
|
|
|
* If the value is negative then we do alpha check.
|
|
|
|
|
* The absolute value itself is the discard factor.
|
|
|
|
|
* Initialize value to 1.0.f if you don't want discard */
|
|
|
|
|
float alpha_discard;
|
2020-06-22 19:57:53 +02:00
|
|
|
float tria_type;
|
|
|
|
|
float _pad[3];
|
2018-04-05 18:51:08 +02:00
|
|
|
} uiWidgetBaseParameters;
|
|
|
|
|
|
|
|
|
|
enum {
|
2019-04-17 06:17:24 +02:00
|
|
|
ROUNDBOX_TRIA_NONE = 0,
|
|
|
|
|
ROUNDBOX_TRIA_ARROWS,
|
|
|
|
|
ROUNDBOX_TRIA_SCROLL,
|
|
|
|
|
ROUNDBOX_TRIA_MENU,
|
|
|
|
|
ROUNDBOX_TRIA_CHECK,
|
|
|
|
|
ROUNDBOX_TRIA_HOLD_ACTION_ARROW,
|
|
|
|
|
|
|
|
|
|
ROUNDBOX_TRIA_MAX, /* don't use */
|
2018-04-05 18:51:08 +02:00
|
|
|
};
|
|
|
|
|
|
2020-06-22 19:57:53 +02:00
|
|
|
struct GPUBatch *ui_batch_roundbox_widget_get(void);
|
2018-07-18 00:12:21 +02:00
|
|
|
struct GPUBatch *ui_batch_roundbox_shadow_get(void);
|
2018-04-05 18:51:08 +02:00
|
|
|
|
2018-07-05 23:30:53 +02:00
|
|
|
void ui_draw_anti_tria_rect(const rctf *rect, char dir, const float color[4]);
|
2009-04-10 14:06:24 +00:00
|
|
|
void ui_draw_menu_back(struct uiStyle *style, uiBlock *block, rcti *rect);
|
2020-05-26 15:39:49 -04:00
|
|
|
void ui_draw_box_opaque(rcti *rect, int roundboxalign);
|
2020-05-12 12:02:28 +10:00
|
|
|
void ui_draw_popover_back(struct ARegion *region,
|
|
|
|
|
struct uiStyle *style,
|
|
|
|
|
uiBlock *block,
|
|
|
|
|
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);
|
2019-01-04 09:58:03 +11:00
|
|
|
const struct uiWidgetColors *ui_tooltip_get_theme(void);
|
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);
|
2020-03-15 17:32:25 +11:00
|
|
|
void ui_draw_tooltip_background(const struct uiStyle *UNUSED(style), uiBlock *block, rcti *rect);
|
2009-06-03 18:31:37 +00:00
|
|
|
|
2020-05-12 12:02:28 +10:00
|
|
|
extern void ui_draw_but(const struct bContext *C,
|
|
|
|
|
struct ARegion *region,
|
|
|
|
|
struct uiStyle *style,
|
|
|
|
|
uiBut *but,
|
|
|
|
|
rcti *rect);
|
2009-04-09 18:11:18 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void ui_draw_menu_item(const struct uiFontStyle *fstyle,
|
|
|
|
|
rcti *rect,
|
|
|
|
|
const char *name,
|
|
|
|
|
int iconid,
|
|
|
|
|
int state,
|
2020-04-14 18:46:13 +10:00
|
|
|
bool use_sep,
|
2020-04-17 11:16:48 +10:00
|
|
|
int *r_xmax);
|
2019-04-17 06:17:24 +02:00
|
|
|
void ui_draw_preview_item(
|
|
|
|
|
const struct uiFontStyle *fstyle, rcti *rect, const char *name, int iconid, int state);
|
2009-06-02 18:10:06 +00:00
|
|
|
|
2013-01-17 18:59:19 +00:00
|
|
|
#define UI_TEXT_MARGIN_X 0.4f
|
2014-11-10 13:58:03 +01:00
|
|
|
#define UI_POPUP_MARGIN (UI_DPI_FAC * 12)
|
2015-10-17 00:21:35 +11:00
|
|
|
/* margin at top of screen for popups */
|
|
|
|
|
#define UI_POPUP_MENU_TOP (int)(8 * UI_DPI_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
|
|
|
|
2009-04-09 18:11:18 +00:00
|
|
|
/* interface_style.c */
|
|
|
|
|
void uiStyleInit(void);
|
2009-04-02 15:01:11 +00:00
|
|
|
|
2009-06-25 15:41:27 +00:00
|
|
|
/* interface_icons.c */
|
2015-05-11 16:29:12 +02:00
|
|
|
void ui_icon_ensure_deferred(const struct bContext *C, const int icon_id, const bool big);
|
2015-01-01 23:26:03 +11:00
|
|
|
int ui_id_icon_get(const struct bContext *C, struct ID *id, const bool big);
|
2009-06-25 15:41:27 +00:00
|
|
|
|
2018-07-08 11:57:59 +02:00
|
|
|
/* interface_icons_event.c */
|
|
|
|
|
void icon_draw_rect_input(
|
2019-04-17 06:17:24 +02:00
|
|
|
float x, float y, int w, int h, float alpha, short event_type, short event_value);
|
2018-07-08 11:57:59 +02:00
|
|
|
|
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
|
|
|
/* resources.c */
|
2018-06-08 12:16:37 +02:00
|
|
|
void init_userdef_do_versions(struct Main *bmain);
|
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
|
|
|
void ui_resources_init(void);
|
|
|
|
|
void ui_resources_free(void);
|
|
|
|
|
|
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
|
|
|
/* interface_layout.c */
|
2009-06-27 01:15:31 +00:00
|
|
|
void ui_layout_add_but(uiLayout *layout, uiBut *but);
|
2020-05-02 02:06:16 +02:00
|
|
|
bool ui_layout_replace_but_ptr(uiLayout *layout, const void *old_but_ptr, uiBut *new_but);
|
|
|
|
|
uiBut *ui_but_add_search(uiBut *but,
|
|
|
|
|
PointerRNA *ptr,
|
|
|
|
|
PropertyRNA *prop,
|
|
|
|
|
PointerRNA *searchptr,
|
|
|
|
|
PropertyRNA *searchprop);
|
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 */
|
2019-03-25 20:31:06 +11:00
|
|
|
void ui_item_menutype_func(struct bContext *C, struct uiLayout *layout, void *arg_mt);
|
2018-05-25 15:46:22 +02:00
|
|
|
void ui_item_paneltype_func(struct bContext *C, struct uiLayout *layout, void *arg_pt);
|
2009-04-10 14:06:24 +00:00
|
|
|
|
2015-11-07 17:31:28 +11:00
|
|
|
/* interface_align.c */
|
2015-11-07 17:36:10 +11:00
|
|
|
bool ui_but_can_align(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
2020-05-12 12:02:28 +10:00
|
|
|
int ui_but_align_opposite_to_area_align_get(const struct ARegion *region) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
void ui_block_align_calc(uiBlock *block, const struct ARegion *region);
|
2015-11-07 17:31:28 +11:00
|
|
|
|
2009-04-03 23:30:32 +00:00
|
|
|
/* interface_anim.c */
|
T77086 Animation: Passing Dependency Graph to Drivers
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
2020-07-17 17:38:09 +02:00
|
|
|
void ui_but_anim_flag(uiBut *but, const struct AnimationEvalContext *anim_eval_context);
|
2009-09-25 04:51:04 +00:00
|
|
|
void ui_but_anim_copy_driver(struct bContext *C);
|
|
|
|
|
void ui_but_anim_paste_driver(struct bContext *C);
|
2014-01-20 11:13:53 +11:00
|
|
|
bool ui_but_anim_expression_get(uiBut *but, char *str, size_t maxlen);
|
|
|
|
|
bool ui_but_anim_expression_set(uiBut *but, const char *str);
|
|
|
|
|
bool ui_but_anim_expression_create(uiBut *but, const char *str);
|
2010-01-12 03:01:19 +00:00
|
|
|
void ui_but_anim_autokey(struct bContext *C, uiBut *but, struct Scene *scene, float cfra);
|
2018-06-16 18:26:34 +02:00
|
|
|
|
2018-06-16 14:48:21 +02:00
|
|
|
void ui_but_anim_decorate_cb(struct bContext *C, void *arg_but, void *arg_dummy);
|
2020-05-03 21:03:22 +02:00
|
|
|
void ui_but_anim_decorate_update_from_flag(uiButDecorator *but);
|
2009-04-03 23:30:32 +00:00
|
|
|
|
2018-06-30 10:36:40 +02:00
|
|
|
/* interface_query.c */
|
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;
|
|
|
|
|
bool ui_but_is_interactive(const uiBut *but, const bool labeledit) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
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;
|
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
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-04-17 06:17:24 +02:00
|
|
|
bool ui_but_contains_point_px_icon(const uiBut *but,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
const struct wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
2020-03-06 16:56:42 +01:00
|
|
|
bool ui_but_contains_point_px(const uiBut *but, const struct ARegion *region, int x, int y)
|
2019-04-17 06:17:24 +02:00
|
|
|
ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_list_find_mouse_over(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
const struct wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_but_find_mouse_over_ex(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
const int x,
|
|
|
|
|
const int y,
|
|
|
|
|
const bool labeledit) ATTR_WARN_UNUSED_RESULT;
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_but_find_mouse_over(struct ARegion *region,
|
2019-04-17 06:17:24 +02:00
|
|
|
const struct wmEvent *event) ATTR_WARN_UNUSED_RESULT;
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_but_find_rect_over(const struct ARegion *region,
|
2019-04-23 16:43:50 +10:00
|
|
|
const rcti *rect_px) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_list_find_mouse_over_ex(struct ARegion *region, int x, int y) ATTR_WARN_UNUSED_RESULT;
|
2019-03-22 18:51:04 +11:00
|
|
|
|
|
|
|
|
bool ui_but_contains_password(const uiBut *but) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
2020-03-13 01:19:22 +11:00
|
|
|
uiBlock *ui_block_find_mouse_over_ex(const struct ARegion *region,
|
|
|
|
|
const int x,
|
|
|
|
|
const int y,
|
|
|
|
|
bool only_clip);
|
|
|
|
|
uiBlock *ui_block_find_mouse_over(const struct ARegion *region,
|
|
|
|
|
const struct wmEvent *event,
|
|
|
|
|
bool only_clip);
|
|
|
|
|
|
2020-03-06 16:56:42 +01:00
|
|
|
uiBut *ui_region_find_first_but_test_flag(struct ARegion *region,
|
|
|
|
|
int flag_include,
|
|
|
|
|
int flag_exclude);
|
|
|
|
|
uiBut *ui_region_find_active_but(struct ARegion *region) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_region_contains_point_px(const struct ARegion *region,
|
|
|
|
|
int x,
|
|
|
|
|
int y) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
bool ui_region_contains_rect_px(const struct ARegion *region, const rcti *rect_px);
|
2018-06-30 10:36:40 +02:00
|
|
|
|
2020-05-12 12:02:28 +10:00
|
|
|
struct ARegion *ui_screen_region_find_mouse_over_ex(struct bScreen *screen, int x, int y);
|
|
|
|
|
struct ARegion *ui_screen_region_find_mouse_over(struct bScreen *screen,
|
|
|
|
|
const struct wmEvent *event);
|
2019-07-31 19:10:44 +02:00
|
|
|
|
2018-06-24 10:01:13 +02:00
|
|
|
/* interface_context_menu.c */
|
|
|
|
|
bool ui_popup_context_menu_for_button(struct bContext *C, uiBut *but);
|
2020-04-03 22:20:25 -05:00
|
|
|
void ui_popup_context_menu_for_panel(struct bContext *C,
|
|
|
|
|
struct ARegion *region,
|
|
|
|
|
struct Panel *panel);
|
2018-06-24 10:01:13 +02:00
|
|
|
|
2013-10-08 15:07:52 +00:00
|
|
|
/* interface_eyedropper.c */
|
2016-02-29 18:46:20 +01:00
|
|
|
struct wmKeyMap *eyedropper_modal_keymap(struct wmKeyConfig *keyconf);
|
2017-12-12 10:19:55 +11:00
|
|
|
struct wmKeyMap *eyedropper_colorband_modal_keymap(struct wmKeyConfig *keyconf);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
|
|
|
|
/* interface_eyedropper_color.c */
|
2013-10-08 15:07:52 +00:00
|
|
|
void UI_OT_eyedropper_color(struct wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
|
|
|
|
/* interface_eyedropper_colorband.c */
|
2019-03-18 18:20:44 +11:00
|
|
|
void UI_OT_eyedropper_colorramp(struct wmOperatorType *ot);
|
|
|
|
|
void UI_OT_eyedropper_colorramp_point(struct wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
|
|
|
|
/* interface_eyedropper_datablock.c */
|
2013-10-08 15:32:54 +00:00
|
|
|
void UI_OT_eyedropper_id(struct wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
|
|
|
|
/* interface_eyedropper_depth.c */
|
2015-01-14 08:01:40 +11:00
|
|
|
void UI_OT_eyedropper_depth(struct wmOperatorType *ot);
|
2017-12-12 15:16:13 +11:00
|
|
|
|
|
|
|
|
/* interface_eyedropper_driver.c */
|
Driver Setup Workflow Improvement: Property Eyedropper
This commit brings some long requested improvements to the workflow for setting up
drivers, which should make it easier and faster to set up new drivers in a more
interactive fashion.
The new workflow is as follows:
1) Hover over the property (e.g. "Lamp Energy" or "Y Location") or properties ("Rotation")
you wish to add drivers to. We'll refer to this as the "destination"
2) Ctrl-D to active the new "Add Drivers" eyedropper
3) Click on the property you want to use as the source/target. The property under the
mouse will be used to drive the property you invoked Ctrl-D on.
For example, to drive the X, Y, and Z location of the Cube using the Y Location of the Lamp,
hover over any of the X/Y/Z location buttons, hit Ctrl-D, then click on the Y-Location
button of the Lamp object. Drivers will be added to the X, Y, and Z Location properties
of the Cube; each driver will have a single variable, which uses the Y-Location Transform
Channel of the Lamp.
Tips:
- Transform properties will automatically create "Transform Channel" driver variables.
Everything else will use "Single Property" ones
- Due to the way that Blender's UI Context works, you'll need two Properties Panel instances
open (and to have pinned one of the two to show the properties for the unselected
object). It's slightly clunky, but necessary for implementing a workflow like this,
as the UI cannot be manipulated while using eyedroppers to pick data.
- The eyedropper operator implemented here actually has three modes of operation.
1) The "1-N" (one to many) mode is the default used for Ctrl-D, and "Add Driver to All"
in the RMB Menu. This is the behaviour described above.
2) There's also a "1-1" (one to one) mode that is used for the "Add Single Driver" in the
RMB Menu.
3) Finally, there's the "N-N" mode (many to many), which isn't currently exposed.
The point of this is to allow mapping XYZ to XYZ elementwise (i.e. direct copying)
which is useful for things like locations, rotations, scaling, and colours.
Implementation Notes:
- The bulk of the driver adding logic is in editors/animation/drivers.c, where most of
the Driver UI operators and tools are defined
- The property eyedropper code is in interface_eyedropper.c along with all the other
eyedroppers (even though they don't share much actual code in common). However, this
turns out to be necessary, as we can't get access to many of the low-level buttons API's
otherwise.
Todo:
- It may be necessary to restore a way to access the old behaviour (i.e. "manual setup")
in case it is not practical to immediately pick a property.
- Other things to investigate here include extra hotkeys (e.g. Ctrl-Shift-D for Add Single?),
and to expose the N-N mode.
- Other things we could try include interactively applying scaling factors, picking
multiple targets (e.g. for location difference and rotation difference drivers),
and/or other ways of using these property picking methods.
2016-03-26 17:55:42 +13:00
|
|
|
void UI_OT_eyedropper_driver(struct wmOperatorType *ot);
|
2013-10-08 15:07:52 +00:00
|
|
|
|
2019-10-11 13:28:22 +02:00
|
|
|
/* interface_eyedropper_gpencil_color.c */
|
|
|
|
|
void UI_OT_eyedropper_gpencil_color(struct wmOperatorType *ot);
|
|
|
|
|
|
2017-05-12 01:42:42 +02:00
|
|
|
/* interface_util.c */
|
2020-05-06 15:51:23 +10:00
|
|
|
bool ui_str_has_word_prefix(const char *haystack, const char *needle, size_t needle_len);
|
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
|
|
|
*/
|
|
|
|
|
typedef struct uiRNACollectionSearch {
|
2019-04-17 06:17:24 +02:00
|
|
|
PointerRNA target_ptr;
|
|
|
|
|
PropertyRNA *target_prop;
|
2017-05-12 01:42:42 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
PointerRNA search_ptr;
|
|
|
|
|
PropertyRNA *search_prop;
|
2017-05-12 01:42:42 +02:00
|
|
|
|
2020-04-08 23:08:32 +02:00
|
|
|
uiBut *search_but;
|
|
|
|
|
/* Let UI_butstore_ API update search_but pointer above over redraws. */
|
|
|
|
|
uiButStore *butstore;
|
|
|
|
|
/* Block has to be stored for freeing butstore (uiBut.block doesn't work with undo). */
|
|
|
|
|
uiBlock *butstore_block;
|
2017-05-12 01:42:42 +02:00
|
|
|
} uiRNACollectionSearch;
|
2020-05-07 23:16:05 +10:00
|
|
|
void ui_rna_collection_search_update_fn(const struct bContext *C,
|
|
|
|
|
void *arg,
|
|
|
|
|
const char *str,
|
|
|
|
|
uiSearchItems *items);
|
2017-05-12 01:42:42 +02:00
|
|
|
|
2019-03-15 10:49:26 -03:00
|
|
|
/* interface_ops.c */
|
|
|
|
|
bool ui_jump_to_target_button_poll(struct bContext *C);
|
|
|
|
|
|
2019-10-01 01:59:31 +10:00
|
|
|
/* interface_queries.c */
|
|
|
|
|
void ui_interface_tag_script_reload_queries(void);
|
