griefith/test
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
286cbc8317bdbe9f2eaebb5df8ecccb53bc830f4
test/source/blender/editors/interface/interface.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

6591 lines
189 KiB
C++
Raw Normal View History

Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
/* SPDX-FileCopyrightText: 2001-2002 NaN Holding BV. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0-or-later */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
doxygen: add newline after \file While \file doesn't need an argument, it can't have another doxy command after it.
2019-02-18 08:08:12 +11:00
/** \file
* \ingroup edinterface
doxygen: blender/editors tagged.
2011-02-27 20:29:51 +00:00
*/
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
#include <cctype>
#include <cfloat>
#include <climits>
#include <cmath>
#include <cstddef> /* `offsetof()` */
#include <cstring>
fix for building on msvc2008 (also style cleanup)
2012-09-04 01:23:50 +00:00
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
#include <fmt/format.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
#include "MEM_guardedalloc.h"
Add eyedropper for selecting object & obdata In addition to the unlink icon to clear a value, When cleared, show an eyedropper to select objects or object-data (was already available via the EKey).
2015-04-21 14:24:13 +10:00
#include "DNA_object_types.h"
2.5: Added basic insert/remove keyframes from UI buttons. - I key over a button inserts a keyframe. - Alt+I removes a keyframe. - With right mouse button a menu with these options pops up. - Buttons are colored green if the property is animated, yellow if it is on a keyframe. I followed the colors from the UI mockups, but the flicker on keyframes seems too distracting in practice? - This only works for properties on the ID itself at the moment, path callbacks need to be filled in for all structs but mesh still. - It doesn't work when you're over a related label, that needs to be made to work. - I made it insert keyframes outside of any keyingset. Not sure how this is supposed to integrate?
2009-04-03 23:30:32 +00:00
#include "DNA_scene_types.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
#include "DNA_screen_types.h"
#include "DNA_userdef_types.h"
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
#include "BLI_ghash.h"
code cleanup: move file string defines into BLI_path_utils.h, BKE_utildefines is now unused but keep incase we want to add defines there later.
2012-09-03 22:04:14 +00:00
#include "BLI_listbase.h"
Cleanup: `make format` after SortedIncludes change
2020-03-19 09:33:03 +01:00
#include "BLI_rect.h"
code cleanup: move file string defines into BLI_path_utils.h, BKE_utildefines is now unused but keep incase we want to add defines there later.
2012-09-03 22:04:14 +00:00
#include "BLI_string.h"
#include "BLI_string_utf8.h"
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
#include "BLI_vector.hh"
code cleanup: move file string defines into BLI_path_utils.h, BKE_utildefines is now unused but keep incase we want to add defines there later.
2012-09-03 22:04:14 +00:00
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BLI_utildefines.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
#include "BKE_animsys.h"
Cleanup: Move several blenkernel headers to C++ Mostly focus on areas where we're already using C++ features, where combining C and C++ APIs is getting in the way. Pull Request: https://projects.blender.org/blender/blender/pulls/114972
2023-11-16 11:41:55 +01:00
#include "BKE_context.hh"
Cleanup: Move BKE_idprop.h to C++
2024-03-26 12:57:30 -04:00
#include "BKE_idprop.hh"
Cleanup: Make `BKE_report.h` a full Cpp header.
2024-02-10 18:34:29 +01:00
#include "BKE_report.hh"
Cleanup: Make `BKE_scene.h` a full Cpp header.
2024-02-10 19:16:25 +01:00
#include "BKE_scene.hh"
Cleanup: Move BKE_screen.h to C++ See #103343
2023-09-25 17:48:21 -04:00
#include "BKE_screen.hh"
Cleanup: Move four blenkernel headers to C++
2023-11-28 16:05:12 -05:00
#include "BKE_unit.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: Move remaining GPU headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/119807
2024-03-23 01:24:18 +01:00
#include "GPU_matrix.hh"
#include "GPU_state.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: Move BLF headers to C++
2024-01-31 14:04:56 -05:00
#include "BLF_api.hh"
Clenup: Move BLT headers to Cpp. Noisy but fairly straight forward.
2024-02-09 18:59:42 +01:00
#include "BLT_translation.hh"
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
Cleanup: Remove unnecessary C wrappers for UI view classes
2024-03-08 09:16:00 -05:00
#include "UI_abstract_view.hh"
Cleanup: quiet compiler warning (missing-declarations)
2023-06-06 09:42:09 +10:00
#include "UI_interface.hh"
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "UI_interface_icons.hh"
UI: show recently selected items at the top of searches The goal is to make the search faster to use by dynamically adapting to the user. This can be achieved using the simple but common approach of showing recently selected items at the top. Note, that the "matching score" between the query and each search item still has precedence when determining the order. So the last used item is only at the top, if there is no other search item that matches the query better. Besides making the search generally faster to use, my hope is that this can also reduce the need for manually weighting search items in some places. This is because while the ordering might not be perfect the first time, it will always be once the user selected the element that should be at the top once. This patch includes: * Support for taking recent searches into account in string searching. * Keep track of a global list of recent searches. * Store recent searches on disk similar to recently opened files. * A new setting in the user preferences that allows disabling the functionality. This can be used if deterministic key strokes are required, e.g. for automated tests. In the future this could be improved in different ways: * Add some kind of separator in the search list to indicate which elements are at the top because they have been used recently. * Store the recent search items per search, instead of in a global list. This way it could adapt to the user even better. Pull Request: https://projects.blender.org/blender/blender/pulls/110828
2023-09-25 10:56:12 +02:00
#include "UI_string_search.hh"
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "UI_view2d.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: move imbuf .h files to .hh
2024-01-18 22:50:23 +02:00
#include "IMB_imbuf.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
#include "WM_api.hh"
#include "WM_message.hh"
#include "WM_types.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
RNA: move headers to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/111022
2023-08-10 22:40:27 +02:00
#include "RNA_access.hh"
UI: Input Placeholders Optional inline hint describing the expected value of an input field. Pull Request: #112104
2023-10-12 11:44:08 -07:00
#include "RNA_enum_types.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: move Python script execution into BPY_extern_run.h This commit renames 'execute' to 'run' because: - This follows Python's "PyRun" which these functions wrap. - Execution functions can use either exec/eval modes, making naming awkward (for future API refactoring).
2020-08-17 17:46:06 +10:00
#ifdef WITH_PYTHON
# include "BPY_extern_run.h"
#endif
adding back button evaluation so you can do 1/60, 90*0.1 etc as well as dimension conversion 1km-10cm+4ft Note... - Python3.1 you don't need to add the .0 for divisions anymore (was esp annoying for button eval) - Simple dimension input, imperial mi/yd/ft/in, metric km/m/cm/mm, Later could display these values and have a pref for scene scale, atm it assumes 1BU == 1m.
2009-08-10 11:58:53 +00:00
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "ED_numinput.hh"
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
#include "ED_screen.hh"
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
Cleanup: move imbuf .h files to .hh
2024-01-18 22:50:23 +02:00
#include "IMB_colormanagement.hh"
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
Cleanup: Move interface_intern.hh The entire interface directory is now compiled as C++ files.
2022-11-26 00:21:17 -06:00
#include "interface_intern.hh"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
using blender::StringRef;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
using blender::Vector;
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
/* prototypes. */
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
static void ui_def_but_rna__menu(bContext *C, uiLayout *layout, void *but_p);
Cleanup: replace UNUSED macro with commented args in C++ code This is the conventional way of dealing with unused arguments in C++, since it works on all compilers. Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
2022-10-03 17:37:25 -05:00
static void ui_def_but_rna__panel_type(bContext * /*C*/, uiLayout *layout, void *but_p);
static void ui_def_but_rna__menu_type(bContext * /*C*/, uiLayout *layout, void *but_p);
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
/* avoid unneeded calls to ui_but_value_get */
minor speedup for UI draw code, noticed ui_get_but_val() could be called 3-5 times per button draw, for RNA buttons this gets the entire array for each call so its not great to call many times.
2011-06-16 06:00:02 +00:00
#define UI_BUT_VALUE_UNSET DBL_MAX
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
#define UI_GET_BUT_VALUE_INIT(_but, _value) \
if (_value == DBL_MAX) { \
(_value) = ui_but_value_get(_but); \
} \
((void)0)
minor speedup for UI draw code, noticed ui_get_but_val() could be called 3-5 times per button draw, for RNA buttons this gets the entire array for each call so its not great to call many times.
2011-06-16 06:00:02 +00:00
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
#define B_NOP -1
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
/**
* a full doc with API notes can be found in 'blender/doc/guides/interface_API.txt'
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
*
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* `uiBlahBlah()` external function.
* `ui_blah_blah()` internal function.
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
*/
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_but_free(const bContext *C, 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
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
static bool ui_but_is_unit_radians_ex(const UnitSettings *unit, const int unit_type)
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
{
return (unit->system_rotation == USER_UNIT_ROT_RADIANS && unit_type == PROP_UNIT_ROTATION);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static bool ui_but_is_unit_radians(const uiBut *but)
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
{
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
const UnitSettings *unit = but->block->unit;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
const int unit_type = UI_but_unit_type_get(but);
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
return ui_but_is_unit_radians_ex(unit, unit_type);
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +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
/* ************* window matrix ************** */
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_block_to_region_fl(const ARegion *region, const uiBlock *block, float *x, float *y)
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
{
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int getsizex = BLI_rcti_size_x(&region->winrct) + 1;
const int getsizey = BLI_rcti_size_y(&region->winrct) + 1;
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
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
float gx = *x;
float gy = *y;
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (block->panel) {
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
gx += block->panel->ofsx;
gy += block->panel->ofsy;
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x = float(getsizex) *
(0.5f + 0.5f * (gx * block->winmat[0][0] + gy * block->winmat[1][0] + block->winmat[3][0]));
*y = float(getsizey) *
(0.5f + 0.5f * (gx * block->winmat[0][1] + gy * block->winmat[1][1] + block->winmat[3][1]));
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
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_block_to_window_fl(const ARegion *region, const uiBlock *block, float *x, float *y)
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
{
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
ui_block_to_region_fl(region, block, x, y);
*x += region->winrct.xmin;
*y += region->winrct.ymin;
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_block_to_window(const ARegion *region, const uiBlock *block, int *x, int *y)
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
{
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
float fx = *x;
float fy = *y;
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
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_block_to_window_fl(region, block, &fx, &fy);
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
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x = int(lround(fx));
*y = int(lround(fy));
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
}
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
void ui_block_to_region_rctf(const ARegion *region,
Cleanup: Use const for UI coordinate conversion functions
2023-06-22 20:30:12 +02:00
const uiBlock *block,
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
rctf *rct_dst,
const rctf *rct_src)
{
*rct_dst = *rct_src;
ui_block_to_region_fl(region, block, &rct_dst->xmin, &rct_dst->ymin);
ui_block_to_region_fl(region, block, &rct_dst->xmax, &rct_dst->ymax);
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
void ui_block_to_window_rctf(const ARegion *region,
Cleanup: Use const for UI coordinate conversion functions
2023-06-22 20:30:12 +02:00
const uiBlock *block,
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
rctf *rct_dst,
const rctf *rct_src)
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
{
fix [#35346] Python: still UI issue with popup and dropdown list
2013-06-13 09:12:53 +00:00
*rct_dst = *rct_src;
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_block_to_window_fl(region, block, &rct_dst->xmin, &rct_dst->ymin);
ui_block_to_window_fl(region, block, &rct_dst->xmax, &rct_dst->ymax);
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
}
Cleanup: Use const for UI coordinate conversion functions
2023-06-22 20:30:12 +02:00
float ui_block_to_window_scale(const ARegion *region, const uiBlock *block)
Preferences: remove tweak/drag threshold distinction Currently the preferences have both tweak and drag threshold, this is confusing because most actions users would consider dragging use the 'tweak' setting. Now one drag threshold is used for both, with a maximum limit of half the button unit-size in case of dragging UI elements.
2019-02-11 15:34:19 +11:00
{
/* We could have function for this to avoid dummy arg. */
float min_y = 0, max_y = 1;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
float dummy_x = 0.0f;
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_block_to_window_fl(region, block, &dummy_x, &min_y);
Fix use of uninitialized stack memory The matrix multiply uses x,y values so both must be initialized.
2019-03-12 15:17:26 +11:00
dummy_x = 0.0f;
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_block_to_window_fl(region, block, &dummy_x, &max_y);
Preferences: remove tweak/drag threshold distinction Currently the preferences have both tweak and drag threshold, this is confusing because most actions users would consider dragging use the 'tweak' setting. Now one drag threshold is used for both, with a maximum limit of half the button unit-size in case of dragging UI elements.
2019-02-11 15:34:19 +11:00
return max_y - min_y;
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_window_to_block_fl(const ARegion *region, const uiBlock *block, float *x, float *y)
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
{
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int getsizex = BLI_rcti_size_x(&region->winrct) + 1;
const int getsizey = BLI_rcti_size_y(&region->winrct) + 1;
const int sx = region->winrct.xmin;
const int sy = region->winrct.ymin;
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
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
const float a = 0.5f * float(getsizex) * block->winmat[0][0];
const float b = 0.5f * float(getsizex) * block->winmat[1][0];
const float c = 0.5f * float(getsizex) * (1.0f + block->winmat[3][0]);
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
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
const float d = 0.5f * float(getsizey) * block->winmat[0][1];
const float e = 0.5f * float(getsizey) * block->winmat[1][1];
const float f = 0.5f * float(getsizey) * (1.0f + block->winmat[3][1]);
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
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
const float px = *x - sx;
const float py = *y - sy;
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
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*y = (a * (py - f) + d * (c - px)) / (a * e - d * b);
*x = (px - b * (*y) - c) / a;
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (block->panel) {
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x -= block->panel->ofsx;
*y -= block->panel->ofsy;
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11: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
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
void ui_window_to_block_rctf(const ARegion *region,
Cleanup: Use const for UI coordinate conversion functions
2023-06-22 20:30:12 +02:00
const uiBlock *block,
UI: add ui_window_to_block_rctf, ui_window_to_region_rcti
2019-04-23 16:39:14 +10:00
rctf *rct_dst,
const rctf *rct_src)
{
*rct_dst = *rct_src;
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_window_to_block_fl(region, block, &rct_dst->xmin, &rct_dst->ymin);
ui_window_to_block_fl(region, block, &rct_dst->xmax, &rct_dst->ymax);
UI: add ui_window_to_block_rctf, ui_window_to_region_rcti
2019-04-23 16:39:14 +10:00
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_window_to_block(const ARegion *region, const uiBlock *block, int *x, int *y)
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
{
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
float fx = *x;
float fy = *y;
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
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_window_to_block_fl(region, block, &fx, &fy);
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
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x = int(lround(fx));
*y = int(lround(fy));
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
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_window_to_region(const ARegion *region, int *x, int *y)
* make function to map mouse into region coords
2008-12-03 20:57:23 +00:00
{
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x -= region->winrct.xmin;
*y -= region->winrct.ymin;
* make function to map mouse into region coords
2008-12-03 20:57:23 +00:00
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
void ui_window_to_region_rcti(const ARegion *region, rcti *rect_dst, const rcti *rct_src)
UI: add ui_window_to_block_rctf, ui_window_to_region_rcti
2019-04-23 16:39:14 +10:00
{
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
rect_dst->xmin = rct_src->xmin - region->winrct.xmin;
rect_dst->xmax = rct_src->xmax - region->winrct.xmin;
rect_dst->ymin = rct_src->ymin - region->winrct.ymin;
rect_dst->ymax = rct_src->ymax - region->winrct.ymin;
UI: add ui_window_to_block_rctf, ui_window_to_region_rcti
2019-04-23 16:39:14 +10:00
}
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
void ui_window_to_region_rctf(const ARegion *region, rctf *rect_dst, const rctf *rct_src)
{
rect_dst->xmin = rct_src->xmin - region->winrct.xmin;
rect_dst->xmax = rct_src->xmax - region->winrct.xmin;
rect_dst->ymin = rct_src->ymin - region->winrct.ymin;
rect_dst->ymax = rct_src->ymax - region->winrct.ymin;
}
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
void ui_region_to_window(const ARegion *region, int *x, int *y)
Input Method Editor (IME) support for text buttons Original patch by @random (D765) with some minor work done by @campbell and me. At this place, I'd like call out a number of people who were involved and deserve a big "Thank you!": * At the first place @randon who developed and submitted the patch * The Blendercn community which helped a lot with testing - espacially * @yuzukyo, @leon_cheung and @kjym3 * @campbellbarton, @mont29 and @sergey for their help and advises during * review * @ton who realized the importance of this early on and asked me for * reviewing We are still not finished, as this is only the first part of the implementaion, but there's more to come!
2014-12-07 00:58:17 +01:00
{
Cleanup: correct invalid use of "r_" prefixed return arguments These arguments are modified in-place and aren't output-only variables.
2024-05-06 11:57:59 +10:00
*x += region->winrct.xmin;
*y += region->winrct.ymin;
Input Method Editor (IME) support for text buttons Original patch by @random (D765) with some minor work done by @campbell and me. At this place, I'd like call out a number of people who were involved and deserve a big "Thank you!": * At the first place @randon who developed and submitted the patch * The Blendercn community which helped a lot with testing - espacially * @yuzukyo, @leon_cheung and @kjym3 * @campbellbarton, @mont29 and @sergey for their help and advises during * review * @ton who realized the importance of this early on and asked me for * reviewing We are still not finished, as this is only the first part of the implementaion, but there's more to come!
2014-12-07 00:58:17 +01:00
}
UI: avoid subtracting shadow from winrct For popup interactions we need to know if events are in the region or not, however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup. Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
2015-08-18 14:16:58 +10:00
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
static void ui_update_flexible_spacing(const ARegion *region, uiBlock *block)
{
int sepr_flex_len = 0;
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
if (but->type == UI_BTYPE_SEPR_SPACER) {
sepr_flex_len++;
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
if (sepr_flex_len == 0) {
return;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
rcti rect;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
ui_but_to_pixelrect(&rect, region, block, static_cast<const uiBut *>(block->buttons.last));
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
const float buttons_width = float(rect.xmax) + UI_HEADER_OFFSET;
Refactor: U.dpi_fac -> U.scale_factor A renaming of UI scale factors from names that imply a relationship to monitor DPI to names that imply that they simply change "scale" Pull Request: https://projects.blender.org/blender/blender/pulls/105750
2023-03-17 04:19:05 +01:00
const float region_width = float(region->sizex) * UI_SCALE_FAC;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
if (region_width <= buttons_width) {
return;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
/* We could get rid of this loop if we agree on a max number of spacer */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
Vector<int, 8> spacers_pos;
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
if (but->type == UI_BTYPE_SEPR_SPACER) {
ui_but_to_pixelrect(&rect, region, block, but);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
spacers_pos.append(rect.xmax + UI_HEADER_OFFSET);
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Fix pin icon in Properties not right-aligned after zooming The logic for separator-spacers (used here for right-alignment) didn't take region scaling into account. Usually that's not an issue because they are otherwise only used in headers which can't zoom.
2020-11-18 19:49:20 +01:00
const float view_scale_x = UI_view2d_scale_get_x(&region->v2d);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
const float segment_width = region_width / float(sepr_flex_len);
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
float offset = 0, remaining_space = region_width - buttons_width;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
int i = 0;
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
Fix pin icon in Properties not right-aligned after zooming The logic for separator-spacers (used here for right-alignment) didn't take region scaling into account. Usually that's not an issue because they are otherwise only used in headers which can't zoom.
2020-11-18 19:49:20 +01:00
BLI_rctf_translate(&but->rect, offset / view_scale_x, 0);
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
if (but->type == UI_BTYPE_SEPR_SPACER) {
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
/* How much the next block overlap with the current segment */
Cleanup: style
2018-06-14 11:37:24 +02:00
int overlap = ((i == sepr_flex_len - 1) ? buttons_width - spacers_pos[i] :
(spacers_pos[i + 1] - spacers_pos[i]) / 2);
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int segment_end = segment_width * (i + 1);
const int spacer_end = segment_end - overlap;
const int spacer_sta = spacers_pos[i] + offset;
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
if (spacer_end > spacer_sta) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const float step = min_ff(remaining_space, spacer_end - spacer_sta);
UI: Make spacers align blocks on area divisions This solves the problem of blocks jumping around when changing modes and center them to the area (in case of only 2 spacers). Which is (in my own opinion) more aestetically pleasing.
2018-06-14 11:29:44 +02:00
remaining_space -= step;
offset += step;
}
i++;
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
}
}
ui_block_bounds_calc(block);
}
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
static void ui_update_window_matrix(const wmWindow *window, const ARegion *region, uiBlock *block)
{
/* window matrix and aspect */
if (region && region->visible) {
/* Get projection matrix which includes View2D translation and zoom. */
GPU_matrix: use Blender's naming conventions Thanks to @sergey for review
2018-07-15 15:27:15 +02:00
GPU_matrix_projection_get(block->winmat);
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
block->aspect = 2.0f / fabsf(region->winx * block->winmat[0][0]);
}
else {
Cleanup: spelling in comments, replace slang/informal terms
2023-05-24 20:27:13 +10:00
/* No sub-window created yet, for menus for example, so we use the main
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
* window instead, since buttons are created there anyway. */
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int width = WM_window_pixels_x(window);
const int height = WM_window_pixels_y(window);
const rcti winrct = {0, width - 1, 0, height - 1};
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
wmGetProjectionMatrix(block->winmat, &winrct);
block->aspect = 2.0f / fabsf(width * block->winmat[0][0]);
}
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
void ui_region_winrct_get_no_margin(const ARegion *region, rcti *r_rect)
UI: avoid subtracting shadow from winrct For popup interactions we need to know if events are in the region or not, however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup. Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
2015-08-18 14:16:58 +10:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBlock *block = static_cast<uiBlock *>(region->uiblocks.first);
Fix T45847: Pie looses focus when mouse cursor passes through a pie button
2015-08-19 20:53:16 +02:00
if (block && (block->flag & UI_BLOCK_LOOP) && (block->flag & UI_BLOCK_RADIAL) == 0) {
UI: avoid subtracting shadow from winrct For popup interactions we need to know if events are in the region or not, however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup. Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
2015-08-18 14:16:58 +10:00
BLI_rcti_rctf_copy_floor(r_rect, &block->rect);
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
BLI_rcti_translate(r_rect, region->winrct.xmin, region->winrct.ymin);
UI: avoid subtracting shadow from winrct For popup interactions we need to know if events are in the region or not, however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup. Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
2015-08-18 14:16:58 +10:00
}
else {
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
*r_rect = region->winrct;
UI: avoid subtracting shadow from winrct For popup interactions we need to know if events are in the region or not, however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup. Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
2015-08-18 14:16:58 +10:00
}
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* ******************* block calc ************************* */
UI: fix popovers not properly working with scroll arrows for long menus.
2018-05-13 18:23:21 +02:00
void UI_block_translate(uiBlock *block, int x, int y)
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
{
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
BLI_rctf_translate(&but->rect, x, y);
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
}
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
BLI_rctf_translate(&block->rect, x, y);
2.5: * Automatic shortcut keys in menus now compare operator properties as well. Implemented IDP_EqualsProperties for this. * I imagine all these compares may be a bit slow, for this case it's not so bad though because it only happens for one menu when it is opened.
2009-01-28 23:29:27 +00:00
}
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
static bool ui_but_is_row_alignment_group(const uiBut *left, const uiBut *right)
{
const bool is_same_align_group = (left->alignnr && (left->alignnr == right->alignnr));
return is_same_align_group && (left->rect.xmin < right->rect.xmin);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_block_bounds_calc_text(uiBlock *block, float offset)
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
{
Cleanup: use 'const' style argument
2020-03-15 17:32:25 +11:00
const uiStyle *style = UI_style_get();
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
uiBut *col_bt;
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
int i = 0, j, x1addval = offset;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_fontstyle_set(&style->widget);
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *init_col_bt = static_cast<uiBut *>(block->buttons.first);
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, bt, &block->buttons) {
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
if (!ELEM(bt->type, UI_BTYPE_SEPR, UI_BTYPE_SEPR_LINE, UI_BTYPE_SEPR_SPACER)) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
j = BLF_width(style->widget.uifont_id, bt->drawstr.c_str(), bt->drawstr.size());
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
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (j > i) {
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
i = j;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
}
2.5: Modifiers & Menus * Popup menus now remember the last clicked item again. * Modifier and File Format menus are now organized in multiple columns with categories. * Hook, explode, uv project modifiers have all their buttons again with the relevant operators implemented. * Modifiers that can't be added by the user, or don't work on curves for example, are not in the menu anymore. * Fix search menu overlapping buttons when near the bottom of the screen. * Fix uv layers search menu not working in some modifiers. * Cleanup popup menu code a bit, layout engine is used in more cases now instead of ugly position calculation code.
2009-08-21 02:51:56 +00:00
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
/* Skip all buttons that are in a horizontal alignment group.
Cleanup: spelling
2020-09-16 15:28:02 +10:00
* We don't want to split them apart (but still check the row's width and apply current
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
* offsets). */
if (bt->next && ui_but_is_row_alignment_group(bt, bt->next)) {
int width = 0;
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int alignnr = bt->alignnr;
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
for (col_bt = bt; col_bt && col_bt->alignnr == alignnr; col_bt = col_bt->next) {
width += BLI_rctf_size_x(&col_bt->rect);
col_bt->rect.xmin += x1addval;
col_bt->rect.xmax += x1addval;
}
if (width > i) {
i = width;
}
/* Give the following code the last button in the alignment group, there might have to be a
* split immediately after. */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
bt = col_bt ? col_bt->prev : nullptr;
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
}
if (bt && bt->next && bt->rect.xmin < bt->next->rect.xmin) {
Cleanup: spelling Also use doxy formatting for warning/note.
2016-01-17 13:40:30 +11:00
/* End of this column, and it's not the last one. */
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
for (col_bt = init_col_bt; col_bt->prev != bt; col_bt = col_bt->next) {
col_bt->rect.xmin = x1addval;
col_bt->rect.xmax = x1addval + i + block->bounds;
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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(col_bt); /* clips text again */
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
}
2.5: Modifiers & Menus * Popup menus now remember the last clicked item again. * Modifier and File Format menus are now organized in multiple columns with categories. * Hook, explode, uv project modifiers have all their buttons again with the relevant operators implemented. * Modifiers that can't be added by the user, or don't work on curves for example, are not in the menu anymore. * Fix search menu overlapping buttons when near the bottom of the screen. * Fix uv layers search menu not working in some modifiers. * Cleanup popup menu code a bit, layout engine is used in more cases now instead of ugly position calculation code.
2009-08-21 02:51:56 +00:00
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
/* And we prepare next column. */
style cleanup: interface
2012-03-30 01:51:25 +00:00
x1addval += i + block->bounds;
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
i = 0;
init_col_bt = col_bt;
Fix T37847: some buttons displayed too wide in multi-column menus.
2013-12-18 19:33:54 +01:00
}
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
}
/* Last column. */
for (col_bt = init_col_bt; col_bt; col_bt = col_bt->next) {
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
/* Recognize a horizontally arranged alignment group and skip its items. */
if (col_bt->next && ui_but_is_row_alignment_group(col_bt, col_bt->next)) {
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int alignnr = col_bt->alignnr;
UI: Add support for row-aligned icon buttons in menus This adds support for drawing icon buttons as a row in menus. This is needed for drawing collection color tagging icons in the outliner context menu in T77777. Part of T77408 Differential Revision: https://developer.blender.org/D8317
2020-09-15 07:19:57 -06:00
for (; col_bt && col_bt->alignnr == alignnr; col_bt = col_bt->next) {
/* pass */
}
}
if (!col_bt) {
break;
}
Fix T39234: popup menus behave poorly when they have not enough width for all their columns. Issue fixed by: * Not having constant width for all columns, but adapt each to its content's width; * Adapting undo's menu height to undo list length (so that we never have more than three columns). It is still possible to get issues in extreme cases (small screen, high DPI size, long op names everywhere...), but this should now be rare corner cases. Also fixes a minor glitch with undo menu (first column had one item less than the others...).
2014-04-15 16:49:49 +02:00
col_bt->rect.xmin = x1addval;
col_bt->rect.xmax = max_ff(x1addval + i + block->bounds, offset + block->minbounds);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(col_bt); /* clips text again */
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
}
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void ui_block_bounds_calc(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
{
ListBase API: add utility api funcs for clearing and checking empty
2014-02-08 06:07:10 +11:00
if (BLI_listbase_is_empty(&block->buttons)) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (block->panel) {
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
block->rect.xmin = 0.0;
block->rect.xmax = block->panel->sizex;
block->rect.ymin = 0.0;
block->rect.ymax = block->panel->sizey;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
else {
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rctf_init_minmax(&block->rect);
2.5: Modifiers & Menus * Popup menus now remember the last clicked item again. * Modifier and File Format menus are now organized in multiple columns with categories. * Hook, explode, uv project modifiers have all their buttons again with the relevant operators implemented. * Modifiers that can't be added by the user, or don't work on curves for example, are not in the menu anymore. * Fix search menu overlapping buttons when near the bottom of the screen. * Fix uv layers search menu not working in some modifiers. * Cleanup popup menu code a bit, layout engine is used in more cases now instead of ugly position calculation code.
2009-08-21 02:51:56 +00:00
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, bt, &block->buttons) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rctf_union(&block->rect, &bt->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
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
block->rect.xmin -= block->bounds;
block->rect.ymin -= block->bounds;
block->rect.xmax += block->bounds;
block->rect.ymax += block->bounds;
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
}
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
block->rect.xmax = block->rect.xmin + max_ff(BLI_rctf_size_x(&block->rect), block->minbounds);
2.5: Modifiers & Menus * Popup menus now remember the last clicked item again. * Modifier and File Format menus are now organized in multiple columns with categories. * Hook, explode, uv project modifiers have all their buttons again with the relevant operators implemented. * Modifiers that can't be added by the user, or don't work on curves for example, are not in the menu anymore. * Fix search menu overlapping buttons when near the bottom of the screen. * Fix uv layers search menu not working in some modifiers. * Cleanup popup menu code a bit, layout engine is used in more cases now instead of ugly position calculation code.
2009-08-21 02:51:56 +00:00
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* hardcoded exception... but that one is annoying with larger safety */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *bt = static_cast<uiBut *>(block->buttons.first);
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
const int xof = ((bt && STRPREFIX(bt->str.c_str(), "ERROR")) ? 10 : 40) * UI_SCALE_FAC;
style cleanup: interface
2012-03-30 01:51:25 +00:00
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
block->safety.xmin = block->rect.xmin - xof;
block->safety.ymin = block->rect.ymin - xof;
block->safety.xmax = block->rect.xmax + xof;
block->safety.ymax = block->rect.ymax + xof;
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_block_bounds_calc_centered(wmWindow *window, uiBlock *block)
Splash screen, implemented by Matt. * Now has documentation links and recent files. * Click on image or outside splash to make it go away. * Still has old image, new one will be committed later.
2009-11-23 13:58:55 +00:00
{
Cleanup: consistent use of tags: NOTE/TODO/FIXME/XXX Also use doxy style function reference `#` prefix chars when referencing identifiers.
2021-07-03 23:08:40 +10:00
/* NOTE: this is used for the splash where window bounds event has not been
Holiday coding log :) Nice formatted version (pictures soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability Short list of main changes: - Transparent region option (over main region), added code to blend in/out such panels. - Min size window now 640 x 480 - Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake. - Macbook retina support, use command line --no-native-pixels to disable it - Timeline Marker label was drawing wrong - Trackpad and magic mouse: supports zoom (hold ctrl) - Fix for splash position: removed ghost function and made window size update after creation immediate - Fast undo buffer save now adds UI as well. Could be checked for regular file save even... Quit.blend and temp file saving use this now. - Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)" - New Userpref option "Keep Session" - this always saves quit.blend, and loads on start. This allows keeping UI and data without actual saves, until you actually save. When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header) - Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v). Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards. - User preferences (themes, keymaps, user settings) now can be saved as a separate file. Old option is called "Save Startup File" the new one "Save User Settings". To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still. - OSX: fixed bug that stopped giving mouse events outside window. This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
* updated by ghost, get the window bounds from ghost directly */
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int xmax = WM_window_pixels_x(window);
const int ymax = WM_window_pixels_y(window);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
ui_block_bounds_calc(block);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int width = BLI_rctf_size_x(&block->rect);
const int height = BLI_rctf_size_y(&block->rect);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int startx = (xmax * 0.5f) - (width * 0.5f);
const int starty = (ymax * 0.5f) - (height * 0.5f);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_translate(block, startx - block->rect.xmin, starty - block->rect.ymin);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
/* now recompute bounds and safety */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(block);
Splash screen, implemented by Matt. * Now has documentation links and recent files. * Click on image or outside splash to make it go away. * Still has old image, new one will be committed later.
2009-11-23 13:58:55 +00: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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_block_bounds_calc_centered_pie(uiBlock *block)
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
{
const int xy[2] = {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
int(block->pie_data.pie_center_spawned[0]),
int(block->pie_data.pie_center_spawned[1]),
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
};
UI: fix popovers not properly working with scroll arrows for long menus.
2018-05-13 18:23:21 +02:00
UI_block_translate(block, xy[0], xy[1]);
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
/* now recompute bounds and safety */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(block);
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_block_bounds_calc_popup(
Fix T52999: floating (popup) panels/menus could jump around screen in some cases. Would happen during panel's refresh drawing, if drawing code had to adjust final panel position compared to the initial one computed based on the mouse coordinates, and user had dragged the floating panel around. Issue fixed by adjusting stored mouse coordinates once final panel position is known, such that they would directly generate those coordinates. that way, the basic offset applied to those stored mouse coordinates during panel dragging is valid, and recreating panel based on those won't make it jump in screen. Note that panel will still jump in case user dragged it partially out of view - we could prevent that, but imho it's better to keep that behavior, since redraw can generate a popup of different size, which could end up with a totally out-of-view one... Hopefully this fix does not break anything else!
2017-10-12 14:43:45 +02:00
wmWindow *window, uiBlock *block, eBlockBoundsCalc bounds_calc, const int xy[2], int r_xy[2])
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
{
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int oldbounds = block->bounds;
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
UI * Changed uiPupMenuOperator usage to uiPupMenuBegin/End (simpler, no need to build a string). Also made transform orientation and subdiv type enums instead of ints for this. * Added an icon argument to many of the uiMenu calls, and added a uiMenuItemIntO. * Move auto rna button creation out of outliner code, now is uiDefAutoButR for individual buttons and uiDefAutoButsRNA for a whole block. * Implemented uiPupBlock(O). Pressing F6 gives a menu with the properties of the last operator to test. I tried to make a redo last operator out of this but couldn't get the context correct for the operator to repeat in. Further the popup block also has some issues getting closed while editing buttons. * Fix uiAfterFunc memory leak on Ctrl+Q quit. * Fix handling of RNA number button dragging and sliding for RNA buttons with range -inf/inf.
2009-02-04 11:52:16 +00:00
/* compute mouse position with user defined offset */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(block);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int xmax = WM_window_pixels_x(window);
const int ymax = WM_window_pixels_y(window);
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
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int oldwidth = BLI_rctf_size_x(&block->rect);
int oldheight = BLI_rctf_size_y(&block->rect);
Fix #20502: add constraint (with targets) menu has no last used memory. The last click button memory can now deal with menus with varying amounts of menu entries and multi column layouts.
2010-02-01 11:13:55 +00:00
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
/* first we ensure wide enough text bounds */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (bounds_calc == UI_BLOCK_BOUNDS_POPUP_MENU) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (block->flag & UI_BLOCK_LOOP) {
Holiday coding log :) Nice formatted version (pictures soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability Short list of main changes: - Transparent region option (over main region), added code to blend in/out such panels. - Min size window now 640 x 480 - Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake. - Macbook retina support, use command line --no-native-pixels to disable it - Timeline Marker label was drawing wrong - Trackpad and magic mouse: supports zoom (hold ctrl) - Fix for splash position: removed ghost function and made window size update after creation immediate - Fast undo buffer save now adds UI as well. Could be checked for regular file save even... Quit.blend and temp file saving use this now. - Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)" - New Userpref option "Keep Session" - this always saves quit.blend, and loads on start. This allows keeping UI and data without actual saves, until you actually save. When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header) - Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v). Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards. - User preferences (themes, keymaps, user settings) now can be saved as a separate file. Old option is called "Save Startup File" the new one "Save User Settings". To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still. - OSX: fixed bug that stopped giving mouse events outside window. This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
block->bounds = 2.5f * UI_UNIT_X;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc_text(block, block->rect.xmin);
UI * Changed uiPupMenuOperator usage to uiPupMenuBegin/End (simpler, no need to build a string). Also made transform orientation and subdiv type enums instead of ints for this. * Added an icon argument to many of the uiMenu calls, and added a uiMenuItemIntO. * Move auto rna button creation out of outliner code, now is uiDefAutoButR for individual buttons and uiDefAutoButsRNA for a whole block. * Implemented uiPupBlock(O). Pressing F6 gives a menu with the properties of the last operator to test. I tried to make a redo last operator out of this but couldn't get the context correct for the operator to repeat in. Further the popup block also has some issues getting closed while editing buttons. * Fix uiAfterFunc memory leak on Ctrl+Q quit. * Fix handling of RNA number button dragging and sliding for RNA buttons with range -inf/inf.
2009-02-04 11:52:16 +00:00
}
}
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
/* next we recompute bounds */
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = oldbounds;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(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
/* and we adjust the position to fit within window */
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int width = BLI_rctf_size_x(&block->rect);
const int height = BLI_rctf_size_y(&block->rect);
whitespace only, no functional change mixed tabs/spaces --> tabs.
2011-04-21 13:11:51 +00:00
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
/* avoid divide by zero below, caused by calling with no UI, but better not crash */
Cleanup: use std::min/max instead of MIN2/MAX2 macros
2023-11-07 16:33:19 +11:00
oldwidth = oldwidth > 0 ? oldwidth : std::max(1, width);
oldheight = oldheight > 0 ? oldheight : std::max(1, height);
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
Fix #20502: add constraint (with targets) menu has no last used memory. The last click button memory can now deal with menus with varying amounts of menu entries and multi column layouts.
2010-02-01 11:13:55 +00:00
/* offset block based on mouse position, user offset is scaled
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
* along in case we resized the block in ui_block_bounds_calc_text */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
rcti rect;
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int raw_x = rect.xmin = xy[0] + block->rect.xmin +
(block->bounds_offset[0] * width) / oldwidth;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int raw_y = rect.ymin = xy[1] + block->rect.ymin +
(block->bounds_offset[1] * height) / oldheight;
Fix popup menu glitch, scrolling at high dpi Popups were clamped be screen-margin, then clipped by UI_POPUP_MENU_TOP, causing regular popups not to have enough room & add scroll buttons.
2015-10-17 00:23:57 +11:00
rect.xmax = rect.xmin + width;
rect.ymax = rect.ymin + height;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
rcti rect_bounds;
const int margin = UI_SCREEN_MARGIN;
Fix popup menu glitch, scrolling at high dpi Popups were clamped be screen-margin, then clipped by UI_POPUP_MENU_TOP, causing regular popups not to have enough room & add scroll buttons.
2015-10-17 00:23:57 +11:00
rect_bounds.xmin = margin;
rect_bounds.ymin = margin;
rect_bounds.xmax = xmax - margin;
rect_bounds.ymax = ymax - UI_POPUP_MENU_TOP;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int ofs_dummy[2];
Fix popup menu glitch, scrolling at high dpi Popups were clamped be screen-margin, then clipped by UI_POPUP_MENU_TOP, causing regular popups not to have enough room & add scroll buttons.
2015-10-17 00:23:57 +11:00
BLI_rcti_clamp(&rect, &rect_bounds, ofs_dummy);
UI: fix popovers not properly working with scroll arrows for long menus.
2018-05-13 18:23:21 +02:00
UI_block_translate(block, rect.xmin - block->rect.xmin, rect.ymin - block->rect.ymin);
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
/* now recompute bounds and safety */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(block);
Fix T52999: floating (popup) panels/menus could jump around screen in some cases. Would happen during panel's refresh drawing, if drawing code had to adjust final panel position compared to the initial one computed based on the mouse coordinates, and user had dragged the floating panel around. Issue fixed by adjusting stored mouse coordinates once final panel position is known, such that they would directly generate those coordinates. that way, the basic offset applied to those stored mouse coordinates during panel dragging is valid, and recreating panel based on those won't make it jump in screen. Note that panel will still jump in case user dragged it partially out of view - we could prevent that, but imho it's better to keep that behavior, since redraw can generate a popup of different size, which could end up with a totally out-of-view one... Hopefully this fix does not break anything else!
2017-10-12 14:43:45 +02:00
/* If given, adjust input coordinates such that they would generate real final popup position.
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
* Needed to handle correctly floating panels once they have been dragged around,
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
* see #52999. */
Fix T52999: floating (popup) panels/menus could jump around screen in some cases. Would happen during panel's refresh drawing, if drawing code had to adjust final panel position compared to the initial one computed based on the mouse coordinates, and user had dragged the floating panel around. Issue fixed by adjusting stored mouse coordinates once final panel position is known, such that they would directly generate those coordinates. that way, the basic offset applied to those stored mouse coordinates during panel dragging is valid, and recreating panel based on those won't make it jump in screen. Note that panel will still jump in case user dragged it partially out of view - we could prevent that, but imho it's better to keep that behavior, since redraw can generate a popup of different size, which could end up with a totally out-of-view one... Hopefully this fix does not break anything else!
2017-10-12 14:43:45 +02:00
if (r_xy) {
r_xy[0] = xy[0] + block->rect.xmin - raw_x;
r_xy[1] = xy[1] + block->rect.ymin - raw_y;
}
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_bounds_set_normal(uiBlock *block, int addval)
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
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (block == nullptr) {
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
return;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = addval;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS;
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
}
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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_bounds_set_text(uiBlock *block, int addval)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = addval;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS_TEXT;
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
}
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
Cleanup: rename uiBlock.mx,my to bounds_offset Use a name that related to block bounds calculation (mx/my are typically used for mouse x,y).
2019-03-13 16:35:24 +11:00
void UI_block_bounds_set_popup(uiBlock *block, int addval, const int bounds_offset[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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = addval;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS_POPUP_MOUSE;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (bounds_offset != nullptr) {
Cleanup: rename uiBlock.mx,my to bounds_offset Use a name that related to block bounds calculation (mx/my are typically used for mouse x,y).
2019-03-13 16:35:24 +11:00
block->bounds_offset[0] = bounds_offset[0];
block->bounds_offset[1] = bounds_offset[1];
}
else {
block->bounds_offset[0] = 0;
block->bounds_offset[1] = 0;
}
UI * Changed uiPupMenuOperator usage to uiPupMenuBegin/End (simpler, no need to build a string). Also made transform orientation and subdiv type enums instead of ints for this. * Added an icon argument to many of the uiMenu calls, and added a uiMenuItemIntO. * Move auto rna button creation out of outliner code, now is uiDefAutoButR for individual buttons and uiDefAutoButsRNA for a whole block. * Implemented uiPupBlock(O). Pressing F6 gives a menu with the properties of the last operator to test. I tried to make a redo last operator out of this but couldn't get the context correct for the operator to repeat in. Further the popup block also has some issues getting closed while editing buttons. * Fix uiAfterFunc memory leak on Ctrl+Q quit. * Fix handling of RNA number button dragging and sliding for RNA buttons with range -inf/inf.
2009-02-04 11:52:16 +00:00
}
Cleanup: rename uiBlock.mx,my to bounds_offset Use a name that related to block bounds calculation (mx/my are typically used for mouse x,y).
2019-03-13 16:35:24 +11:00
void UI_block_bounds_set_menu(uiBlock *block, int addval, const int bounds_offset[2])
UI * Changed uiPupMenuOperator usage to uiPupMenuBegin/End (simpler, no need to build a string). Also made transform orientation and subdiv type enums instead of ints for this. * Added an icon argument to many of the uiMenu calls, and added a uiMenuItemIntO. * Move auto rna button creation out of outliner code, now is uiDefAutoButR for individual buttons and uiDefAutoButsRNA for a whole block. * Implemented uiPupBlock(O). Pressing F6 gives a menu with the properties of the last operator to test. I tried to make a redo last operator out of this but couldn't get the context correct for the operator to repeat in. Further the popup block also has some issues getting closed while editing buttons. * Fix uiAfterFunc memory leak on Ctrl+Q quit. * Fix handling of RNA number button dragging and sliding for RNA buttons with range -inf/inf.
2009-02-04 11:52:16 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = addval;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS_POPUP_MENU;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (bounds_offset != nullptr) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
copy_v2_v2_int(block->bounds_offset, bounds_offset);
Cleanup: rename uiBlock.mx,my to bounds_offset Use a name that related to block bounds calculation (mx/my are typically used for mouse x,y).
2019-03-13 16:35:24 +11:00
}
else {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
zero_v2_int(block->bounds_offset);
Cleanup: rename uiBlock.mx,my to bounds_offset Use a name that related to block bounds calculation (mx/my are typically used for mouse x,y).
2019-03-13 16:35:24 +11: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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_bounds_set_centered(uiBlock *block, int addval)
Splash screen, implemented by Matt. * Now has documentation links and recent files. * Click on image or outside splash to make it go away. * Still has old image, new one will be committed later.
2009-11-23 13:58:55 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->bounds = addval;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS_POPUP_CENTER;
Splash screen, implemented by Matt. * Now has documentation links and recent files. * Click on image or outside splash to make it go away. * Still has old image, new one will be committed later.
2009-11-23 13:58:55 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_bounds_set_explicit(uiBlock *block, int minx, int miny, int maxx, int maxy)
Fix for long-standing TODO item: Clicking on overlapping nodes would activate buttons below. This patch adds a new CLIP_EVENTS flag for uiBlock, which will prevent the ui_but_find_mouse_over search function from looking into "lower" uiBlocks (i.e. those further back in the list). The order of block creation for nodes has also been updated to use the z-ordering (just the nodetree->nodes list). In order for this to work, the bounding box values of the uiBlocks have to be set explicitely to fit the node size, those are usually either zero or calculated from the internal buttons.
2011-11-22 17:49:06 +00:00
{
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
block->rect.xmin = minx;
block->rect.ymin = miny;
block->rect.xmax = maxx;
block->rect.ymax = maxy;
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
block->bounds_type = UI_BLOCK_BOUNDS_NONE;
Fix for long-standing TODO item: Clicking on overlapping nodes would activate buttons below. This patch adds a new CLIP_EVENTS flag for uiBlock, which will prevent the ui_but_find_mouse_over search function from looking into "lower" uiBlocks (i.e. those further back in the list). The order of block creation for nodes has also been updated to use the z-ordering (just the nodetree->nodes list). In order for this to work, the bounding box values of the uiBlocks have to be set explicitely to fit the node size, those are usually either zero or calculated from the internal buttons.
2011-11-22 17:49:06 +00:00
}
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
static float ui_but_get_float_precision(uiBut *but)
{
if (but->type == UI_BTYPE_NUM) {
return ((uiButNumber *)but)->precision;
}
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
if (but->type == UI_BTYPE_NUM_SLIDER) {
return ((uiButNumberSlider *)but)->precision;
}
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
BLI_assert_unreachable();
return 1.0f;
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
}
RNA: display exact integer values without fraction if step is integer. Display exact integer values of a floating point fields without a fraction if the step is also an exact integer. This is intended for cases when the value can technically be fractional, but most commonly is supposed to be integer. This handling is not applied if the field has any unit except frames, because integer values aren't special for quantities like length. The fraction is discarded in the normal display mode and when copying the value to clipboard, but not when editing to remind the user that the field allows fractions. Differential Revision: https://developer.blender.org/D13753
2021-12-26 18:09:19 +03:00
static float ui_but_get_float_step_size(uiBut *but)
{
if (but->type == UI_BTYPE_NUM) {
return ((uiButNumber *)but)->step_size;
}
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
if (but->type == UI_BTYPE_NUM_SLIDER) {
return ((uiButNumberSlider *)but)->step_size;
}
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
BLI_assert_unreachable();
return 1.0f;
RNA: display exact integer values without fraction if step is integer. Display exact integer values of a floating point fields without a fraction if the step is also an exact integer. This is intended for cases when the value can technically be fractional, but most commonly is supposed to be integer. This handling is not applied if the field has any unit except frames, because integer values aren't special for quantities like length. The fraction is discarded in the normal display mode and when copying the value to clipboard, but not when editing to remind the user that the field allows fractions. Differential Revision: https://developer.blender.org/D13753
2021-12-26 18:09:19 +03:00
}
static bool ui_but_hide_fraction(uiBut *but, double value)
{
/* Hide the fraction if both the value and the step are exact integers. */
if (floor(value) == value) {
const float step = ui_but_get_float_step_size(but) * UI_PRECISION_FLOAT_SCALE;
if (floorf(step) == step) {
/* Don't hide if it has any unit except frame count. */
switch (UI_but_unit_type_get(but)) {
case PROP_UNIT_NONE:
case PROP_UNIT_TIME:
return true;
default:
return false;
}
}
}
return false;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static int ui_but_calc_float_precision(uiBut *but, double value)
Move UI float precission calculation into its own function.
2011-06-07 02:39:40 +00:00
{
RNA: display exact integer values without fraction if step is integer. Display exact integer values of a floating point fields without a fraction if the step is also an exact integer. This is intended for cases when the value can technically be fractional, but most commonly is supposed to be integer. This handling is not applied if the field has any unit except frames, because integer values aren't special for quantities like length. The fraction is discarded in the normal display mode and when copying the value to clipboard, but not when editing to remind the user that the field allows fractions. Differential Revision: https://developer.blender.org/D13753
2021-12-26 18:09:19 +03:00
if (ui_but_hide_fraction(but, value)) {
return 0;
}
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
int prec = int(ui_but_get_float_precision(but));
smarter precision calculation, so 0.000001 isn't displayed as 0.00. there is a minor problem with this commit: 0.00001 --> 0.00001 # good 0.000015 --> 0.000015 # good 0.0000199 --> 0.00002 # ok 0.00002 --> 0.000020 # wrong, has trailing 0 Tried to fix this but the case is hard to check for without more calculations which Id like to avoid.
2011-06-07 04:06:10 +00:00
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
/* first check for various special cases:
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
* * If button is radians, we want additional precision (see #39861).
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
* * If prec is not set, we fallback to a simple default */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ui_but_is_unit_radians(but) && prec < 5) {
Fix T39861: UI destroys float precision. Note this is only a workaround in fact, adding some precision in radians case. Validating the field will still generate a precision loss (doing otherwise is doable-ish, but likely to backfire and/or add too much complexity in an already complex area).
2014-04-24 17:17:55 +02:00
prec = 5;
}
else if (prec == -1) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
prec = (but->hardmax < 10.001f) ? 3 : 2;
smarter precision calculation, so 0.000001 isn't displayed as 0.00. there is a minor problem with this commit: 0.00001 --> 0.00001 # good 0.000015 --> 0.000015 # good 0.0000199 --> 0.00002 # ok 0.00002 --> 0.000020 # wrong, has trailing 0 Tried to fix this but the case is hard to check for without more calculations which Id like to avoid.
2011-06-07 04:06:10 +00:00
}
Add some security checks against future bad float UIprecision values. This commit and previous one should be backported to 2.79a should we release it.
2017-09-18 19:50:40 +02:00
else {
CLAMP(prec, 0, UI_PRECISION_FLOAT_MAX);
}
smarter precision calculation, so 0.000001 isn't displayed as 0.00. there is a minor problem with this commit: 0.00001 --> 0.00001 # good 0.000015 --> 0.000015 # good 0.0000199 --> 0.00002 # ok 0.00002 --> 0.000020 # wrong, has trailing 0 Tried to fix this but the case is hard to check for without more calculations which Id like to avoid.
2011-06-07 04:06:10 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
return UI_calc_float_precision(prec, value);
Fix issues with float precision in numinput, like 'R 123' who would show additional 'noise' digits. Expose float precision helper in UI_interface.h API, so that numinput can use this helper as numbuttons already do. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D186
2014-01-08 17:04:10 +01:00
}
smarter precision calculation, so 0.000001 isn't displayed as 0.00. there is a minor problem with this commit: 0.00001 --> 0.00001 # good 0.000015 --> 0.000015 # good 0.0000199 --> 0.00002 # ok 0.00002 --> 0.000020 # wrong, has trailing 0 Tried to fix this but the case is hard to check for without more calculations which Id like to avoid.
2011-06-07 04:06:10 +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
/* ************** BLOCK ENDING FUNCTION ************* */
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)
{
return ui_but_rna_equals_ex(a, &b->rnapoin, b->rnaprop, b->rnaindex);
}
bool ui_but_rna_equals_ex(const uiBut *but,
const PointerRNA *ptr,
const PropertyRNA *prop,
int index)
{
if (but->rnapoin.data != ptr->data) {
return false;
}
if (but->rnaprop != prop || but->rnaindex != index) {
return false;
}
return true;
}
Cleanup: spelling in comments, minor reformatting changes
2022-04-07 14:48:00 +10:00
/* NOTE: if `but->poin` is allocated memory for every `uiDefBut*`, things fail. */
internal api: args passed to ui_but_equals_old() were wrong order.
2013-07-27 08:06:46 +00:00
static bool ui_but_equals_old(const uiBut *but, const uiBut *oldbut)
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
{
UI: Add callback for comparing button identity The code to compare buttons from the previous to the current frame, to see if they match (an thus should keep the same state) was quite generic, and didn't allow much flexibility/customization. For some cases this isn't enough, and a more specific comparison is needed. Say if some buttons don't actually store comparable data themselves, only via the button context. This was the case in D14653.
2022-04-26 22:26:15 +02:00
if (but->identity_cmp_func) {
Cleanup: Grammar in comments: Fix uses of "own" "Own" (the adjective) cannot be used on its own. It should be combined with something like "its own", "our own", "her own", or "the object's own". It also isn't used separately to mean something like "separate". Also, "its own" is correct instead of "it's own" which is a misues of the verb.
2024-03-07 16:20:36 -05:00
/* If the buttons have their own identity comparator callbacks (and they match), use this to
UI: Add callback for comparing button identity The code to compare buttons from the previous to the current frame, to see if they match (an thus should keep the same state) was quite generic, and didn't allow much flexibility/customization. For some cases this isn't enough, and a more specific comparison is needed. Say if some buttons don't actually store comparable data themselves, only via the button context. This was the case in D14653.
2022-04-26 22:26:15 +02:00
* determine equality. */
if (but->identity_cmp_func && (but->type == oldbut->type) &&
(but->identity_cmp_func == oldbut->identity_cmp_func))
{
/* Test if the comparison is symmetrical (if a == b then b == a), may help catch some issues.
*/
BLI_assert(but->identity_cmp_func(but, oldbut) == but->identity_cmp_func(oldbut, but));
return but->identity_cmp_func(but, oldbut);
}
}
spelling corrections in comments and quiet warning
2011-10-15 14:14:22 +00:00
/* various properties are being compared here, hopefully sufficient
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
* to catch all cases, but it is simple to add more checks later */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->retval != oldbut->retval) {
return false;
}
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
if (!ui_but_rna_equals(but, oldbut)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
return false;
}
if (but->func != oldbut->func) {
return false;
}
UI: Add type-safe C++ button apply function object No user visible changes expected. Rather than relying on a C-style function pointer with void pointer arguments, allow storing a `std::function` object, which can hold arbitrary data in a type safe way. This can be conveniently used with lambdas for example. This is not used yet, but will be with #104831 merged. Replacing the existing C-style callback uses with this can be done separately. Pull Request: https://projects.blender.org/blender/blender/pulls/109016
2023-06-26 16:39:51 +02:00
/* Compares the contained function pointers. Buttons with different apply functions can be
* considered to do different things, and as such do not equal each other. */
if (but->apply_func.target<void(bContext &)>() != oldbut->apply_func.target<void(bContext &)>())
{
return false;
}
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->funcN != oldbut->funcN) {
return false;
}
Cleanup: use ELEM macro
2020-11-06 12:30:59 +11:00
if (!ELEM(oldbut->func_arg1, oldbut, but->func_arg1)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
return false;
}
Cleanup: use ELEM macro
2020-11-06 12:30:59 +11:00
if (!ELEM(oldbut->func_arg2, oldbut, but->func_arg2)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
return false;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
internal api: args passed to ui_but_equals_old() were wrong order.
2013-07-27 08:06:46 +00:00
if (!but->funcN && ((but->poin != oldbut->poin && (uiBut *)oldbut->poin != oldbut) ||
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
(but->pointype != oldbut->pointype)))
{
return false;
}
if (but->optype != oldbut->optype) {
return false;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Asset Browser: Show current file assets in other asset libraries if contained If the current file is saved within an asset library, showing that asset library in the Asset Browser will also display the assets from this current file now. In fact, it's the latest state of the open file, including all unsaved modifications. These assets will show a little Blender icon in the preview image, which is our usual icon for current file data. Note that this means an important design change: The "Current File" asset library isn't the only place to edit assets from anymore. From now on assets from the current file can also be edited in the context of the full asset library. See T90193 for more info. Technical info: Besides just including the assets from the current `Main`, this requires partial clearing and reading of file-lists, so that asset operations (e.g. removing an asset data-block) doesn't require a full reload of the asset library. Maniphest Task: https://developer.blender.org/T90193
2021-10-20 13:09:40 +02:00
if (but->dragtype != oldbut->dragtype) {
return false;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
if ((but->type == UI_BTYPE_VIEW_ITEM) && (oldbut->type == UI_BTYPE_VIEW_ITEM)) {
uiButViewItem *but_item = (uiButViewItem *)but;
uiButViewItem *oldbut_item = (uiButViewItem *)oldbut;
if (!but_item->view_item || !oldbut_item->view_item ||
Cleanup: Remove unnecessary C wrappers for UI view classes
2024-03-08 09:16:00 -05:00
!UI_view_item_matches(*but_item->view_item, *oldbut_item->view_item))
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
{
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
return false;
}
}
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
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
}
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
uiBut *ui_but_find_old(uiBlock *block_old, const uiBut *but_new)
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
{
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block_old->buttons) {
if (ui_but_equals_old(but_new, but)) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
return but;
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
}
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
uiBut *ui_but_find_new(uiBlock *block_new, const uiBut *but_old)
{
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block_new->buttons) {
if (ui_but_equals_old(but, but_old)) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
return but;
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
}
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
UI: Support mouse over highlighting for superimposed icons E.g. the 'x' icons or eyedropper icons in text buttons. They didn't use to have any mouse over feedback, now we dim the icon until hovered. This kind of feedback helps users see that the icons are interactive, and if they are within their interaction hotspot.
2020-09-18 20:10:40 +02:00
static bool ui_but_extra_icons_equals_old(const uiButExtraOpIcon *new_extra_icon,
const uiButExtraOpIcon *old_extra_icon)
{
return (new_extra_icon->optype_params->optype == old_extra_icon->optype_params->optype) &&
(new_extra_icon->icon == old_extra_icon->icon);
}
static uiButExtraOpIcon *ui_but_extra_icon_find_old(const uiButExtraOpIcon *new_extra_icon,
const uiBut *old_but)
{
LISTBASE_FOREACH (uiButExtraOpIcon *, op_icon, &old_but->extra_op_icons) {
if (ui_but_extra_icons_equals_old(new_extra_icon, op_icon)) {
return op_icon;
}
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
UI: Support mouse over highlighting for superimposed icons E.g. the 'x' icons or eyedropper icons in text buttons. They didn't use to have any mouse over feedback, now we dim the icon until hovered. This kind of feedback helps users see that the icons are interactive, and if they are within their interaction hotspot.
2020-09-18 20:10:40 +02:00
}
static void ui_but_extra_icons_update_from_old_but(const uiBut *new_but, const uiBut *old_but)
{
/* Specifically for keeping some state info for the active button. */
BLI_assert(old_but->active);
LISTBASE_FOREACH (uiButExtraOpIcon *, new_extra_icon, &new_but->extra_op_icons) {
uiButExtraOpIcon *old_extra_icon = ui_but_extra_icon_find_old(new_extra_icon, old_but);
/* Keep the highlighting state, and let handling update it later. */
if (old_extra_icon) {
new_extra_icon->highlighted = old_extra_icon->highlighted;
}
}
}
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/**
* Update pointers and other information in the old active button based on new information in the
* corresponding new button from the current layout pass.
*
* \param oldbut: The button from the last layout pass that will be moved to the new block.
* \param but: The newly added button with much of the up to date information, to be feed later.
*
* \note #uiBut has ownership of many of its pointers. When the button is freed all these
* pointers are freed as well, so ownership has to be moved out of \a but in order to free it.
*/
static void ui_but_update_old_active_from_new(uiBut *oldbut, uiBut *but)
{
BLI_assert(oldbut->active);
/* flags from the buttons we want to refresh, may want to add more here... */
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
const int flag_copy = UI_BUT_REDALERT | UI_HAS_ICON | UI_SELECT_DRAW;
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
const int drawflag_copy = UI_BUT_HAS_TOOLTIP_LABEL;
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/* still stuff needs to be copied */
oldbut->rect = but->rect;
oldbut->context = but->context; /* set by Layout */
/* drawing */
oldbut->icon = but->icon;
oldbut->iconadd = but->iconadd;
oldbut->alignnr = but->alignnr;
/* typically the same pointers, but not on undo/redo */
/* XXX some menu buttons store button itself in but->poin. Ugly */
if (oldbut->poin != (char *)oldbut) {
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(oldbut->poin, but->poin);
std::swap(oldbut->func_argN, but->func_argN);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
}
/* Move tooltip from new to old. */
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(oldbut->tip_func, but->tip_func);
std::swap(oldbut->tip_arg, but->tip_arg);
std::swap(oldbut->tip_arg_free, but->tip_arg_free);
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
std::swap(oldbut->tip_label_func, but->tip_label_func);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
oldbut->flag = (oldbut->flag & ~flag_copy) | (but->flag & flag_copy);
oldbut->drawflag = (oldbut->drawflag & ~drawflag_copy) | (but->drawflag & drawflag_copy);
ui_but_extra_icons_update_from_old_but(but, oldbut);
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(but->extra_op_icons, oldbut->extra_op_icons);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
if (oldbut->type == UI_BTYPE_SEARCH_MENU) {
uiButSearch *search_oldbut = (uiButSearch *)oldbut, *search_but = (uiButSearch *)but;
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(search_oldbut->arg_free_fn, search_but->arg_free_fn);
std::swap(search_oldbut->arg, search_but->arg);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
}
/* copy hardmin for list rows to prevent 'sticking' highlight to mouse position
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
* when scrolling without moving mouse (see #28432) */
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
if (ELEM(oldbut->type, UI_BTYPE_ROW, UI_BTYPE_LISTROW)) {
oldbut->hardmax = but->hardmax;
}
UI: Tree-View API for easy creation of tree UIs This follows three main targets: * Make creation of new tree UIs easy. * Groundwork to generalize tree UIs (so e.g. Outliner, animation channels, asset catalogs and spreadsheet data-sets don't have to re-implement basic tree UI code) or even other data-view UIs. * Better separate data and UI state. E.g. with this, tree-item selection or the open/collapsed state can be stored on the UI level, rather than in data. (Asset Catalogs need this, storing UI state info in them is not an option.) In addition, the design should be well testable and could even be exposed to Python. Note that things will likely change in master still. E.g. the actually resulting UI isn't very nice visually yet. The design is documented here: https://wiki.blender.org/wiki/Source/Interface/Views Differential Revision: https://developer.blender.org/D12573
2021-09-23 18:56:29 +02:00
switch (oldbut->type) {
Cleanup: rename uiButProgressbar to uiButProgress Prepare for other types of progress to be added.
2023-07-12 13:15:39 +10:00
case UI_BTYPE_PROGRESS: {
uiButProgress *progress_oldbut = (uiButProgress *)oldbut;
uiButProgress *progress_but = (uiButProgress *)but;
progress_oldbut->progress_factor = progress_but->progress_factor;
UI: Tree-View API for easy creation of tree UIs This follows three main targets: * Make creation of new tree UIs easy. * Groundwork to generalize tree UIs (so e.g. Outliner, animation channels, asset catalogs and spreadsheet data-sets don't have to re-implement basic tree UI code) or even other data-view UIs. * Better separate data and UI state. E.g. with this, tree-item selection or the open/collapsed state can be stored on the UI level, rather than in data. (Asset Catalogs need this, storing UI state info in them is not an option.) In addition, the design should be well testable and could even be exposed to Python. Note that things will likely change in master still. E.g. the actually resulting UI isn't very nice visually yet. The design is documented here: https://wiki.blender.org/wiki/Source/Interface/Views Differential Revision: https://developer.blender.org/D12573
2021-09-23 18:56:29 +02:00
break;
}
Refactor: UI_BTYPE_SEPR_LINE Without Need for uiBut->a1 The line separator needs to know vertical or horizontal orientation at draw time, and is independent of button rect. This PR removes the use of uiBut->a1 for this in favor of a derived struct. Pull Request: https://projects.blender.org/blender/blender/pulls/118969
2024-03-01 18:09:02 +01:00
case UI_BTYPE_SEPR_LINE: {
uiButSeparatorLine *line_oldbut = (uiButSeparatorLine *)oldbut;
uiButSeparatorLine *line_but = (uiButSeparatorLine *)but;
line_oldbut->is_vertical = line_but->is_vertical;
break;
}
Cleanup: UI: Use derived struct for label buttons, remove a1, a2 usage
2024-03-01 13:46:06 -05:00
case UI_BTYPE_LABEL: {
uiButLabel *label_oldbut = (uiButLabel *)oldbut;
uiButLabel *label_but = (uiButLabel *)but;
label_oldbut->alpha_factor = label_but->alpha_factor;
break;
}
Cleanup: UI: Use derived struct for list scroll bars, remove a1, a2 usage
2024-03-01 13:59:03 -05:00
case UI_BTYPE_SCROLL: {
uiButScrollBar *scroll_oldbut = (uiButScrollBar *)oldbut;
uiButScrollBar *scroll_but = (uiButScrollBar *)but;
scroll_oldbut->visual_height = scroll_but->visual_height;
break;
}
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
case UI_BTYPE_VIEW_ITEM: {
uiButViewItem *view_item_oldbut = (uiButViewItem *)oldbut;
uiButViewItem *view_item_newbut = (uiButViewItem *)but;
Cleanup: Remove unnecessary C wrappers for UI view classes
2024-03-08 09:16:00 -05:00
ui_view_item_swap_button_pointers(*view_item_newbut->view_item,
*view_item_oldbut->view_item);
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(view_item_newbut->view_item, view_item_oldbut->view_item);
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
break;
}
UI: Tree-View API for easy creation of tree UIs This follows three main targets: * Make creation of new tree UIs easy. * Groundwork to generalize tree UIs (so e.g. Outliner, animation channels, asset catalogs and spreadsheet data-sets don't have to re-implement basic tree UI code) or even other data-view UIs. * Better separate data and UI state. E.g. with this, tree-item selection or the open/collapsed state can be stored on the UI level, rather than in data. (Asset Catalogs need this, storing UI state info in them is not an option.) In addition, the design should be well testable and could even be exposed to Python. Note that things will likely change in master still. E.g. the actually resulting UI isn't very nice visually yet. The design is documented here: https://wiki.blender.org/wiki/Source/Interface/Views Differential Revision: https://developer.blender.org/D12573
2021-09-23 18:56:29 +02:00
default:
break;
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
}
/* move/copy string from the new button to the old */
/* needed for alt+mouse wheel over enums */
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
std::swap(but->str, oldbut->str);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
Fix wrong asset dropped when dragging from loc. of just cleared asset See previous commit for an explanation of what went wrong. Similar to the fix there, we also have to update the dragged data (e.g. the data-block) referenced by the button. Committing separately since this could cause further issues.
2022-05-31 12:24:03 +02:00
if (but->dragpoin) {
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(but->dragpoin, oldbut->dragpoin);
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
}
Fix T95394: Crash when dragging from location of just cleared asset In Blender buttons are recreated over redraws, except of the active button which is kept alive, and replaces the new version of itself in the new redraw. In order to do that, the button needs to be recognized. This process of recognizing and matching buttons from different redraws isn't always bullet-proof. That's okay-ish, but we have to make sure that the relevant data of the old active button is updated with the newest data. Here the matching would go wrong, and the new active button was recognized as the old active button, which was in fact removed when the asset was cleared. This patch makes sure the image buffer attached to the buttons is updated when buttons were recognized as matching. Note that the dragging will still use the wrong data-block, this will be fixed in the following commit.
2022-05-31 12:03:33 +02:00
if (but->imb) {
Cleanup: Use std::swap instead of macro in C++ code
2023-01-09 11:12:03 -05:00
std::swap(but->imb, oldbut->imb);
Fix T95394: Crash when dragging from location of just cleared asset In Blender buttons are recreated over redraws, except of the active button which is kept alive, and replaces the new version of itself in the new redraw. In order to do that, the button needs to be recognized. This process of recognizing and matching buttons from different redraws isn't always bullet-proof. That's okay-ish, but we have to make sure that the relevant data of the old active button is updated with the newest data. Here the matching would go wrong, and the new active button was recognized as the old active button, which was in fact removed when the asset was cleared. This patch makes sure the image buffer attached to the buttons is updated when buttons were recognized as matching. Note that the dragging will still use the wrong data-block, this will be fixed in the following commit.
2022-05-31 12:03:33 +02:00
}
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
Cleanup: consistent use of tags: NOTE/TODO/FIXME/XXX Also use doxy style function reference `#` prefix chars when referencing identifiers.
2021-07-03 23:08:40 +10:00
/* NOTE: if layout hasn't been applied yet, it uses old button pointers... */
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
/**
* \return true when \a but_p is set (only done for active buttons).
*/
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
static bool ui_but_update_from_old_block(const bContext *C,
uiBlock *block,
uiBut **but_p,
uiBut **but_old_p)
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
{
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
uiBlock *oldblock = block->oldblock;
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
uiBut *but = *but_p;
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
#if 0
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/* Simple method - search every time. Keep this for easy testing of the "fast path." */
uiBut *oldbut = ui_but_find_old(oldblock, but);
UNUSED_VARS(but_old_p);
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
#else
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
BLI_assert(*but_old_p == nullptr || BLI_findindex(&oldblock->buttons, *but_old_p) != -1);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/* As long as old and new buttons are aligned, avoid loop-in-loop (calling #ui_but_find_old). */
uiBut *oldbut;
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
if (LIKELY(*but_old_p && ui_but_equals_old(but, *but_old_p))) {
oldbut = *but_old_p;
}
else {
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/* Fallback to block search. */
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
oldbut = ui_but_find_old(oldblock, but);
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
(*but_old_p) = oldbut ? oldbut->next : nullptr;
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
#endif
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
bool found_active = false;
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
if (!oldbut) {
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
return false;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
if (oldbut->active) {
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
/* Move button over from oldblock to new block. */
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
BLI_remlink(&oldblock->buttons, oldbut);
BLI_insertlinkafter(&block->buttons, but, oldbut);
Fix T81691: Use-after-free with property search and hovered button The list of buttons in the button group needs to be updated to take into account the old button inserted into the button list for the new block. Differential Revision: https://developer.blender.org/D9428
2020-11-03 16:30:58 -06:00
/* Add the old button to the button groups in the new block. */
ui_button_group_replace_but_ptr(block, but, oldbut);
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
oldbut->block = block;
*but_p = oldbut;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
ui_but_update_old_active_from_new(oldbut, but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix rare crash dragging number-buttons Could happen dragging shape-keys UIList & the lower slider at once.
2014-12-01 23:30:54 +01:00
if (!BLI_listbase_is_empty(&block->butstore)) {
UI_butstore_register_update(block, oldbut, but);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
BLI_remlink(&block->buttons, but);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_free(C, but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Cleanup ui_but_update_from_old_block This commit contains some improvements to this function to make this function more purposeful and readable. - Split updating information of the old button to a new function. - Remove some 7 year old code disabled with `#if 0`. - Add comments explaining some of the less obvious aspects. Differential Revision: https://developer.blender.org/D9117
2020-10-24 23:58:32 -05:00
found_active = true;
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
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
else {
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
int flag_copy = UI_BUT_DRAG_MULTI;
Asset Browser: Rework layout & behavior of catalog tree-view This reworks how tree rows are constructed in the layout and how they behave in return. * To open or collapse a row, the triangle/chevron icon has to be clicked now. The previous behavior of allowing to do it on the entire row, but only if the item was active already, was just too unusual and felt weird. * Reduce margin between chevron icon and the row label. * Indent child items without chevron some more, otherwise they feel like a row on the same level as their parent, just without chevron. * Fix renaming button taking entire row width. Respect indentation now. * Fix double-clicking to rename toggling collapsed state on each click. Some hacks/special-handling was needed so tree-rows always highlight while the mouse is hovering them, even if the mouse is actually hovering another button inside the row.
2021-10-07 14:59:43 +02:00
UI: UIList Hover Highlighting Add mouse hover highlighting for items in UILists, in both list mode and preview tile mode. See 104677 for more details Differential Revision: https://projects.blender.org/blender/blender/pulls/104677 Reviewed by Brecht Van Lommel
2023-02-21 13:03:17 -08:00
/* Stupid special case: The active button may be inside (as in, overlapped on top) a row
Asset Browser: Rework layout & behavior of catalog tree-view This reworks how tree rows are constructed in the layout and how they behave in return. * To open or collapse a row, the triangle/chevron icon has to be clicked now. The previous behavior of allowing to do it on the entire row, but only if the item was active already, was just too unusual and felt weird. * Reduce margin between chevron icon and the row label. * Indent child items without chevron some more, otherwise they feel like a row on the same level as their parent, just without chevron. * Fix renaming button taking entire row width. Respect indentation now. * Fix double-clicking to rename toggling collapsed state on each click. Some hacks/special-handling was needed so tree-rows always highlight while the mouse is hovering them, even if the mouse is actually hovering another button inside the row.
2021-10-07 14:59:43 +02:00
* button which we also want to keep highlighted then. */
UI: UIList Hover Highlighting Add mouse hover highlighting for items in UILists, in both list mode and preview tile mode. See 104677 for more details Differential Revision: https://projects.blender.org/blender/blender/pulls/104677 Reviewed by Brecht Van Lommel
2023-02-21 13:03:17 -08:00
if (ELEM(but->type, UI_BTYPE_VIEW_ITEM, UI_BTYPE_LISTROW)) {
UI Code Quality: Rename `UI_ACTIVE` button flag to `UI_HOVER` Calling this state "active" has been confusing for a long time for a number of reasons: - It's not clear that this is essentially a mouse hover state. - Easy to confuse with "select" state (`UI_SELECT`), both terms are vague. - Buttons can be "inactive" (`UI_BUT_INACTIVE`) which is totally related to this "active" state. - Button handling can consider a button as active that doesn't have this flag set (e.g. during text input). - Active and selected are well established terms in Blender, but they mean a different thing there. See #112160. Pull Request: https://projects.blender.org/blender/blender/pulls/114113
2023-10-25 18:36:27 +02:00
flag_copy |= UI_HOVER;
Asset Browser: Rework layout & behavior of catalog tree-view This reworks how tree rows are constructed in the layout and how they behave in return. * To open or collapse a row, the triangle/chevron icon has to be clicked now. The previous behavior of allowing to do it on the entire row, but only if the item was active already, was just too unusual and felt weird. * Reduce margin between chevron icon and the row label. * Indent child items without chevron some more, otherwise they feel like a row on the same level as their parent, just without chevron. * Fix renaming button taking entire row width. Respect indentation now. * Fix double-clicking to rename toggling collapsed state on each click. Some hacks/special-handling was needed so tree-rows always highlight while the mouse is hovering them, even if the mouse is actually hovering another button inside the row.
2021-10-07 14:59:43 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
but->flag = (but->flag & ~flag_copy) | (oldbut->flag & flag_copy);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
/* ensures one button can get activated, and in case the buttons
* draw are the same this gives O(1) lookup for each button */
BLI_remlink(&oldblock->buttons, oldbut);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_free(C, oldbut);
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
return found_active;
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
}
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
bool UI_but_active_only_ex(
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
const bContext *C, ARegion *region, uiBlock *block, uiBut *but, const bool remove_on_failure)
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
{
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
bool activate = false, found = false, isactive = false;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBlock *oldblock = block->oldblock;
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
if (!oldblock) {
activate = true;
}
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
else {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *oldbut = ui_but_find_old(oldblock, but);
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
if (oldbut) {
found = true;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
if (oldbut->active) {
isactive = true;
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
}
}
}
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
if ((activate == true) || (found == false)) {
Fix T78907: Renaming file doesn't work while mouse is over file icon The icons are label buttons. Usually these are not editable and can not become active. These are draggable ones though (so dragging files can be dragged by dragging the icon) which creates an exception to this rule. So hovering the icon would activate its label and when executing the rename operator via shortcut it wouldn't get exited properly. This broke the invariant of only allowing a single active button at a time. Added an assert to check that invariant now. Letting the code to activate the text button ensure any currently active button is exited seems sensible.
2020-08-05 19:34:11 +02:00
/* There might still be another active button. */
uiBut *old_active = ui_region_find_active_but(region);
if (old_active) {
ui_but_active_free(C, old_active);
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_but_activate_event((bContext *)C, region, but);
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
}
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
else if ((found == true) && (isactive == false)) {
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
if (remove_on_failure) {
BLI_remlink(&block->buttons, but);
Fix possible use-after-free when cancelling temporary rename button If a renaming button was removed via `UI_but_active_only_ex()` and that button was placed using the layout system, the button was still in the layout. So far this didn't cause issues, because all cases where the button may be removed were not using the layout system.
2021-10-06 11:20:15 +02:00
if (but->layout) {
ui_layout_remove_but(but->layout, but);
}
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
ui_but_free(C, but);
}
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
2.5 Outliner: brought back to near full functioning: - proper operators, like for open/close items, exec operations (note: select is still same operator as activate, should become modal ops later) - rename works again (ctrl+click) - proper notifiers for redraws - select / extend select works again - editmode in/out works again - enter key opens/closes again - right mouse operations work again Didn't do: - options for Sequence strips - signals to change button views on clicks - error/warning messages UI: - added new uiButSetRenameFunc(), which passes on the old name - added uiButActiveOnly(), which ensures a button gets created in active state, and gets removed when used. Needed for editing names in outliner. Andrea: check outliner.c for uiButActiveOnly(), very easy to use! Also: - Added posemode operator, CTRL+TAB tied to it.
2009-07-25 13:40:59 +00:00
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
bool UI_but_active_only(const bContext *C, ARegion *region, uiBlock *block, uiBut *but)
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
{
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
return UI_but_active_only_ex(C, region, block, but, true);
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
bool UI_block_active_only_flagged_buttons(const bContext *C, ARegion *region, uiBlock *block)
UI: support for popups starting with buttons activated While this could already be done from C, this is now exposed to Python
2019-03-20 22:40:38 +11:00
{
Fix T83539: 'activate_init' fails with buttons that have popups Activating buttons was running too early, before the popup was positioned on the screen, causing data-selectors to be positioned incorrectly. As the early button activation isn't needed, remove this call. Ensure this doesn't happen again with an assert.
2021-01-28 16:12:43 +11:00
/* Running this command before end-block has run, means buttons that open menus
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
* won't have those menus correctly positioned, see #83539. */
Cleanup: Use bool instead of char
2021-02-22 13:18:49 -06:00
BLI_assert(block->endblock);
Fix T83539: 'activate_init' fails with buttons that have popups Activating buttons was running too early, before the popup was positioned on the screen, causing data-selectors to be positioned incorrectly. As the early button activation isn't needed, remove this call. Ensure this doesn't happen again with an assert.
2021-01-28 16:12:43 +11:00
UI: support for popups starting with buttons activated While this could already be done from C, this is now exposed to Python
2019-03-20 22:40:38 +11:00
bool done = false;
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
if (but->flag & UI_BUT_ACTIVATE_ON_INIT) {
but->flag &= ~UI_BUT_ACTIVATE_ON_INIT;
if (ui_but_is_editable(but)) {
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
if (UI_but_active_only_ex(C, region, block, but, false)) {
UI: support for popups starting with buttons activated While this could already be done from C, this is now exposed to Python
2019-03-20 22:40:38 +11:00
done = true;
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
break;
UI: support for popups starting with buttons activated While this could already be done from C, this is now exposed to Python
2019-03-20 22:40:38 +11:00
}
}
}
}
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
if (done) {
/* Run this in a second pass since it's possible activating the button
* removes the buttons being looped over. */
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
Fix crash using 'activate_init' in popup menus Reported in T71112
2020-02-13 16:18:11 +11:00
but->flag &= ~UI_BUT_ACTIVATE_ON_INIT;
}
}
UI: support for popups starting with buttons activated While this could already be done from C, this is now exposed to Python
2019-03-20 22:40:38 +11:00
return done;
}
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
void UI_but_execute(const bContext *C, ARegion *region, uiBut *but)
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
{
UI: split ui_button_execute_do into begin/end
2014-02-08 09:12:59 +11:00
void *active_back;
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_but_execute_begin((bContext *)C, region, but, &active_back);
UI: split ui_button_execute_do into begin/end
2014-02-08 09:12:59 +11:00
/* Value is applied in begin. No further action required. */
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_but_execute_end((bContext *)C, region, but, active_back);
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
}
spelling cleanup
2012-03-18 07:38:51 +00:00
/* use to check if we need to disable undo, but don't make any changes
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
* returns false if undo needs to be disabled. */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static bool ui_but_is_rna_undo(const uiBut *but)
misc changes to unterface & undo - operator strings were doing undo pushes (in fileselector text for example), this is dumb since the operators themselves handle undo. - interface code checks rna props are arrays rather then checking the array length. - disable properties window pin undoing. - sequencer refresh was calling undo, disable since this is clearnign global data not handled by undo. - added commented out code for drawing mesh vertex index/key index, useful for debugging shapekey - hook issyes.
2011-08-18 19:07:37 +00:00
{
Refactor: RNA property undo push only when there is an owner ID RNA pointers should always have valid owner IDs. And most structs using STRUCT_UNDO do not need it because the owner is a UI datablock which already determines if undo is needed. With this change, it is possible to have structs used both in UI and scene datablocks and have undo work depending on the owner. This is needed for collections storing operator properties for export (#116646). Pull Request: https://projects.blender.org/blender/blender/pulls/117640
2024-02-08 15:08:09 +01:00
if (but->rnaprop == nullptr) {
return true;
misc changes to unterface & undo - operator strings were doing undo pushes (in fileselector text for example), this is dumb since the operators themselves handle undo. - interface code checks rna props are arrays rather then checking the array length. - disable properties window pin undoing. - sequencer refresh was calling undo, disable since this is clearnign global data not handled by undo. - added commented out code for drawing mesh vertex index/key index, useful for debugging shapekey - hook issyes.
2011-08-18 19:07:37 +00:00
}
Refactor: RNA property undo push only when there is an owner ID RNA pointers should always have valid owner IDs. And most structs using STRUCT_UNDO do not need it because the owner is a UI datablock which already determines if undo is needed. With this change, it is possible to have structs used both in UI and scene datablocks and have undo work depending on the owner. This is needed for collections storing operator properties for export (#116646). Pull Request: https://projects.blender.org/blender/blender/pulls/117640
2024-02-08 15:08:09 +01:00
/* No owner or type known. Assume we do not undo push as it may be a property from
* the preferences stored outside datablocks. */
if (but->rnapoin.owner_id == nullptr || but->rnapoin.type == nullptr) {
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
return false;
- disable undo for user preferences (every click would do push an undo), was noticeable on large files. - also netbeans project file generator now uses branch name for project.
2011-11-08 15:11:27 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: RNA property undo push only when there is an owner ID RNA pointers should always have valid owner IDs. And most structs using STRUCT_UNDO do not need it because the owner is a UI datablock which already determines if undo is needed. With this change, it is possible to have structs used both in UI and scene datablocks and have undo work depending on the owner. This is needed for collections storing operator properties for export (#116646). Pull Request: https://projects.blender.org/blender/blender/pulls/117640
2024-02-08 15:08:09 +01:00
return ID_CHECK_UNDO(but->rnapoin.owner_id) && RNA_struct_undo_check(but->rnapoin.type);
misc changes to unterface & undo - operator strings were doing undo pushes (in fileselector text for example), this is dumb since the operators themselves handle undo. - interface code checks rna props are arrays rather then checking the array length. - disable properties window pin undoing. - sequencer refresh was calling undo, disable since this is clearnign global data not handled by undo. - added commented out code for drawing mesh vertex index/key index, useful for debugging shapekey - hook issyes.
2011-08-18 19:07:37 +00:00
}
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
/* assigns automatic keybindings to menu items for fast access
* (underline key in menu) */
static void ui_menu_block_set_keyaccels(uiBlock *block)
{
Cleanup: use typed unsigned ints
2019-01-04 11:05:53 +11:00
uint menu_key_mask = 0;
style cleanup: interface
2012-03-30 01:51:25 +00:00
int tot_missing = 0;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
/* only do it before bounding */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block->rect.xmin != block->rect.xmax) {
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
return;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: quiet maybe-unused warning While harmless, use flow control that always sets the variable.
2019-08-02 11:18:07 +10:00
for (int pass = 0; pass < 2; pass++) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
/* 2 Passes: One for first letter only, second for any letter if the first pass fails.
* Run first pass on all buttons so first word chars always get first priority. */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: Cleanup (line length)
2014-11-11 16:52:03 +01:00
if (!ELEM(but->type,
UI_BTYPE_BUT,
UI_BTYPE_BUT_MENU,
UI_BTYPE_MENU,
UI_BTYPE_BLOCK,
UI: support A-Z accelerator keys for pie menus Converting menus to PIE's was removing convenient key accelerators.
2020-04-17 15:50:47 +10:00
UI_BTYPE_PULLDOWN,
/* For PIE-menus. */
UI_BTYPE_ROW) ||
UI: Cleanup (line length)
2014-11-11 16:52:03 +01:00
(but->flag & UI_HIDDEN))
{
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
continue;
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (but->menu_key != '\0') {
continue;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
if (but->str.empty()) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
continue;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
const char *str_pt = but->str.c_str();
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
uchar menu_key;
do {
menu_key = tolower(*str_pt);
if ((menu_key >= 'a' && menu_key <= 'z') && !(menu_key_mask & 1 << (menu_key - 'a'))) {
menu_key_mask |= 1 << (menu_key - 'a');
break;
}
if (pass == 0) {
/* Skip to next delimiter on first pass (be picky) */
while (isalpha(*str_pt)) {
str_pt++;
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (*str_pt) {
str_pt++;
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
}
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
else {
/* just step over every char second pass and find first usable key */
str_pt++;
}
} while (*str_pt);
if (*str_pt) {
but->menu_key = menu_key;
}
else {
/* run second pass */
tot_missing++;
}
/* if all keys have been used just exit, unlikely */
if (menu_key_mask == (1 << 26) - 1) {
return;
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
/* check if second pass is needed */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!tot_missing) {
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
break;
}
}
}
code cleanup: use bools in interface handlers, dont show translation menu when right clicking on splash, use less confusing args for copy/paste function.
2013-04-04 15:16:29 +00:00
void ui_but_add_shortcut(uiBut *but, const char *shortcut_str, const bool do_strip)
fix for memory leak displaying shortcuts to buttons which use allocated string, also de-duplocate this code which had this error in 2 places. noticed while testing 1023 length paths.
2012-01-21 22:42:09 +00:00
{
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
if (do_strip && (but->flag & UI_BUT_HAS_SEP_CHAR)) {
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
const size_t sep_index = but->str.find_first_of(UI_SEP_CHAR);
if (sep_index != std::string::npos) {
but->str = but->str.substr(0, sep_index);
fix for memory leak displaying shortcuts to buttons which use allocated string, also de-duplocate this code which had this error in 2 places. noticed while testing 1023 length paths.
2012-01-21 22:42:09 +00:00
}
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
but->flag &= ~UI_BUT_HAS_SEP_CHAR;
fix for memory leak displaying shortcuts to buttons which use allocated string, also de-duplocate this code which had this error in 2 places. noticed while testing 1023 length paths.
2012-01-21 22:42:09 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
fix for memory leak displaying shortcuts to buttons which use allocated string, also de-duplocate this code which had this error in 2 places. noticed while testing 1023 length paths.
2012-01-21 22:42:09 +00:00
/* without this, just allow stripping of the shortcut */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (shortcut_str == nullptr) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
return;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
but->str = fmt::format("{}" UI_SEP_CHAR_S "{}", but->str, shortcut_str);
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
but->flag |= UI_BUT_HAS_SEP_CHAR;
ui_but_update(but);
fix for memory leak displaying shortcuts to buttons which use allocated string, also de-duplocate this code which had this error in 2 places. noticed while testing 1023 length paths.
2012-01-21 22:42:09 +00:00
}
Menu UI feature common in other widget sets: Automatically assign menu keys based on name, alternative to pressing number 0-9 on menus items. keys are assigned by first giving each menu item the first character of any word, if that fails any key in the name is used. - active key is shown underlined. - only ascii keys are assigned currently. - can run operators, open menu items. - currently this only works in cases where number buttons were used (UI_BLOCK_NUMSELECT), but could be enabled for file menu, splash etc by removing this check.
2010-12-14 02:38:29 +00:00
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
/* -------------------------------------------------------------------- */
/** \name Find Key Shortcut for Button
*
* - #ui_but_event_operator_string (and helpers)
* - #ui_but_event_property_operator_string
* \{ */
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_event_operator_string_from_operator(
const bContext *C, wmOperatorCallParams *op_call_params)
UI: various changes * View2D to region now returns ints instead of shorts. * Use "Numpad" instead of "Pad" in automatic keymap menu info. * Menus can now use buttons other than BUTM and SEPR, in particular TOG and ROW are now supported instead of flipping bits manually. * Added a simpler uiDefMenu* api for making menus now, and it only supports Operator and RNA buttons at the moment, will be used in next commit. Not sure how this will evolve .. makes menu code look cleaner anyways. * Ensure that interface code doesn't crash when getting unknown Operators and RNA properties, and display their buttons grayed out in that case.
2009-01-15 04:13:38 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
BLI_assert(op_call_params->optype != nullptr);
IDProperty *prop = reinterpret_cast<IDProperty *>(op_call_params->opptr) ?
static_cast<IDProperty *>(op_call_params->opptr->data) :
nullptr;
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return WM_key_event_operator_string(
C, op_call_params->optype->idname, op_call_params->opcontext, prop, true);
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_event_operator_string_from_menu(const bContext *C,
uiBut *but)
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
{
MenuType *mt = UI_but_menutype_get(but);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
BLI_assert(mt != nullptr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
/* Dummy, name is unimportant. */
IDProperty *prop_menu = blender::bke::idprop::create_group(__func__).release();
BLI_idprop: simplify string creation logic, support unterminated strings - Support passing in unterminated C-strings when clamped by the size argument. - Pair string and it's size arguments together in IDP_NewStringMaxSize. - Remove redundant size check which made it seem as if the string might not be null terminated. - Replace clamping the result of strlen(..) with BLI_strnlen, to avoid calculating the length past the size checked. - Add doc-string for unclamped string creation.
2023-12-05 16:31:54 +11:00
IDP_AddToGroup(prop_menu, IDP_NewStringMaxSize(mt->idname, sizeof(mt->idname), "name"));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
const std::optional<std::string> result = WM_key_event_operator_string(
C, "WM_OT_call_menu", WM_OP_INVOKE_REGION_WIN, prop_menu, true);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
IDP_FreeProperty(prop_menu);
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return result;
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_event_operator_string_from_panel(const bContext *C,
uiBut *but)
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
{
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
using namespace blender;
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
/** Nearly exact copy of #ui_but_event_operator_string_from_menu */
PanelType *pt = UI_but_paneltype_get(but);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
BLI_assert(pt != nullptr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
/* Dummy, name is unimportant. */
IDProperty *prop_panel = bke::idprop::create_group(__func__).release();
BLI_idprop: simplify string creation logic, support unterminated strings - Support passing in unterminated C-strings when clamped by the size argument. - Pair string and it's size arguments together in IDP_NewStringMaxSize. - Remove redundant size check which made it seem as if the string might not be null terminated. - Replace clamping the result of strlen(..) with BLI_strnlen, to avoid calculating the length past the size checked. - Add doc-string for unclamped string creation.
2023-12-05 16:31:54 +11:00
IDP_AddToGroup(prop_panel, IDP_NewStringMaxSize(pt->idname, sizeof(pt->idname), "name"));
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
IDP_AddToGroup(prop_panel, bke::idprop::create("space_type", pt->space_type).release());
IDP_AddToGroup(prop_panel, bke::idprop::create("region_type", pt->region_type).release());
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
BLI_SCOPED_DEFER([&]() { IDP_FreeProperty(prop_panel); });
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
for (int i = 0; i < 2; i++) {
Cleanup: update username in code-comments: campbellbarton -> ideasman42 Gitea migration changed my username, update code-comments.
2023-02-09 11:30:25 +11:00
/* FIXME(@ideasman42): We can't reasonably search all configurations - long term. */
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
IDP_ReplaceInGroup(prop_panel, bke::idprop::create("keep_open", i).release());
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
if (std::optional<std::string> result = WM_key_event_operator_string(
C, "WM_OT_call_panel", WM_OP_INVOKE_REGION_WIN, prop_panel, true))
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
{
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return result;
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return std::nullopt;
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_event_operator_string(const bContext *C, uiBut *but)
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->optype != nullptr) {
wmOperatorCallParams params = {};
params.optype = but->optype;
params.opptr = but->opptr;
params.opcontext = but->opcontext;
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return ui_but_event_operator_string_from_operator(C, &params);
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
if (UI_but_menutype_get(but) != nullptr) {
return ui_but_event_operator_string_from_menu(C, but);
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
if (UI_but_paneltype_get(but) != nullptr) {
return ui_but_event_operator_string_from_panel(C, but);
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return std::nullopt;
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_extra_icon_event_operator_string(
const bContext *C, const uiButExtraOpIcon *extra_icon)
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
{
wmOperatorType *extra_icon_optype = UI_but_extra_operator_icon_optype_get(extra_icon);
if (extra_icon_optype) {
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return ui_but_event_operator_string_from_operator(C, extra_icon->optype_params);
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return std::nullopt;
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::optional<std::string> ui_but_event_property_operator_string(const bContext *C,
uiBut *but)
Cleanup: order buffer length after the buffer
2017-11-06 00:04:46 +11:00
{
Cleanup: Use std::string for WM API function return values
2024-01-29 16:33:06 -05:00
using namespace blender;
Cleanup: remove extra in trailing asterisk Comment blocks not conforming to convention.
2021-01-20 15:15:38 +11:00
/* Context toggle operator names to check. */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use usernames in code-comments Also remove my name in a few cases where it doesn't seem necessary.
2024-01-14 11:48:51 +11:00
/* NOTE(@ideasman42): This function could use a refactor to generalize button type to operator
* relationship as well as which operators use properties. */
Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these up in the userprefs/keymaps editor, it is quite tricky doing so, and most users would just assume that since no shortcut is displayed, there simply isn't one at all. This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties. There are still some corner cases that would be nice to solve too (i.e. the Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!
2013-07-07 12:53:15 +00:00
const char *ctx_toggle_opnames[] = {
"WM_OT_context_toggle",
"WM_OT_context_toggle_enum",
"WM_OT_context_cycle_int",
"WM_OT_context_cycle_enum",
"WM_OT_context_cycle_array",
"WM_OT_context_menu_enum",
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr,
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
};
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
const char *ctx_enum_opnames[] = {
"WM_OT_context_set_enum",
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr,
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
};
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
const char *ctx_enum_opnames_for_Area_ui_type[] = {
"SCREEN_OT_space_type_set_or_cycle",
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr,
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
};
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
const char **opnames = ctx_toggle_opnames;
int opnames_len = ARRAY_SIZE(ctx_toggle_opnames);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
int prop_enum_value = -1;
bool prop_enum_value_ok = false;
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
bool prop_enum_value_is_int = false;
const char *prop_enum_value_id = "value";
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
PointerRNA *ptr = &but->rnapoin;
PropertyRNA *prop = but->rnaprop;
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
int prop_index = but->rnaindex;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if ((but->type == UI_BTYPE_BUT_MENU) && (but->block->handle != nullptr)) {
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
uiBut *but_parent = but->block->handle->popup_create_vars.but;
Cleanup: remove redundant checks for known states
2024-03-29 10:29:47 +11:00
if ((but_parent && but_parent->rnaprop) &&
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
(RNA_property_type(but_parent->rnaprop) == PROP_ENUM) &&
RNA: rename prop_popover_enum to prop_with_popover A version for menu's is going to be added next and we already have UILayout.prop_menu_enum. This name indicates the popover is added behavior instead of a different kind of widget.
2019-03-25 20:10:32 +11:00
ELEM(but_parent->menu_create_func,
ui_def_but_rna__menu,
RNA: add UILayout.prop_with_menu function Matches prop_with_popover, supporting menu types, useful if we want to control behavior of enum switching.
2019-03-25 20:31:06 +11:00
ui_def_but_rna__panel_type,
ui_def_but_rna__menu_type))
{
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
prop_enum_value = int(but->hardmin);
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
ptr = &but_parent->rnapoin;
prop = but_parent->rnaprop;
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
prop_enum_value_ok = true;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
opnames = ctx_enum_opnames;
opnames_len = ARRAY_SIZE(ctx_enum_opnames);
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
/* Don't use the button again. */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
but = nullptr;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (prop == nullptr) {
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return std::nullopt;
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
}
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
/* This version is only for finding hotkeys for properties.
Cleanup: Remove repeated word in comments
2022-02-23 18:24:08 +11:00
* These are set via a data-path which is appended to the context,
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
* manipulated using operators (see #ctx_toggle_opnames). */
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (ptr->owner_id) {
ID *id = ptr->owner_id;
if (GS(id->name) == ID_SCR) {
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
if (RNA_struct_is_a(ptr->type, &RNA_Area)) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
/* data should be directly on here... */
const char *prop_id = RNA_property_identifier(prop);
/* Hack since keys access 'type', UI shows 'ui_type'. */
if (STREQ(prop_id, "ui_type")) {
prop_id = "type";
prop_enum_value >>= 16;
prop = RNA_struct_find_property(ptr, prop_id);
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
prop_index = -1;
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
opnames = ctx_enum_opnames_for_Area_ui_type;
opnames_len = ARRAY_SIZE(ctx_enum_opnames_for_Area_ui_type);
prop_enum_value_id = "space_type";
prop_enum_value_is_int = true;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
}
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
/* There may be multiple data-paths to the same properties,
* support different variations so key bindings are properly detected no matter which are used.
*/
Cleanup: Use std::string for WM API function return values
2024-01-29 16:33:06 -05:00
Vector<std::string, 2> data_path_variations;
Fix some property shortcuts not showing in tooltip Shortcut lookups for property buttons were only supported for a subset of RNA types. Replace inline data-path calculation with WM_context_path_resolve_property_full. Now the shortcut for the 3D View's overlay toggle (for e.g.) is shown.
2021-10-15 16:26:55 +11:00
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
{
Cleanup: use std::optional instead of empty strings for return values When a string shouldn't be used or is invalid, use std::nullopt to make it clear it's value shouldn't be used. Without this it's possible to accidentally use an empty string which will silently fail.
2024-01-30 15:43:16 +11:00
std::optional<std::string> data_path = WM_context_path_resolve_property_full(
C, ptr, prop, prop_index);
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
/* Always iterate once, even if data-path isn't set. */
Cleanup: use "value_or" for optional types instead of ternary operators
2024-02-10 22:35:32 +11:00
data_path_variations.append(data_path.value_or(""));
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
Cleanup: use std::optional instead of empty strings for return values When a string shouldn't be used or is invalid, use std::nullopt to make it clear it's value shouldn't be used. Without this it's possible to accidentally use an empty string which will silently fail.
2024-01-30 15:43:16 +11:00
if (data_path.has_value()) {
StringRef data_path_ref = StringRef(data_path.value());
if (data_path_ref.startswith("scene.tool_settings.")) {
data_path_variations.append(data_path_ref.drop_known_prefix("scene."));
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
}
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
/* We have a data-path! */
Cleanup: remove redundant variable & check
2024-03-28 13:01:34 +11:00
for (int data_path_index = 0; data_path_index < data_path_variations.size(); data_path_index++) {
Cleanup: Use std::string for WM API function return values
2024-01-29 16:33:06 -05:00
const StringRefNull data_path = data_path_variations[data_path_index];
if (!data_path.is_empty() || (prop_enum_value_ok && prop_enum_value_id)) {
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
/* Create a property to host the "data_path" property we're sending to the operators. */
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
IDProperty *prop_path = blender::bke::idprop::create_group(__func__).release();
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
BLI_SCOPED_DEFER([&]() { IDP_FreeProperty(prop_path); });
Cleanup: Use std::string for WM API function return values
2024-01-29 16:33:06 -05:00
if (!data_path.is_empty()) {
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
IDP_AddToGroup(prop_path, bke::idprop::create("data_path", data_path).release());
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
if (prop_enum_value_ok) {
const EnumPropertyItem *item;
bool free;
RNA_property_enum_items((bContext *)C, ptr, prop, &item, nullptr, &free);
const int index = RNA_enum_from_value(item, prop_enum_value);
if (index != -1) {
IDProperty *prop_value;
if (prop_enum_value_is_int) {
const int value = item[index].value;
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
prop_value = bke::idprop::create(prop_enum_value_id, value).release();
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
else {
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
prop_value = bke::idprop::create(prop_enum_value_id, item[index].identifier).release();
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
IDP_AddToGroup(prop_path, prop_value);
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
}
else {
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
opnames_len = 0; /* Do nothing. */
}
if (free) {
MEM_freeN((void *)item);
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
/* check each until one works... */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
for (int i = 0; (i < opnames_len) && (opnames[i]); i++) {
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
if (const std::optional<std::string> str = WM_key_event_operator_string(
C, opnames[i], WM_OP_INVOKE_REGION_WIN, prop_path, false))
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
{
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return str;
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these up in the userprefs/keymaps editor, it is quite tricky doing so, and most users would just assume that since no shortcut is displayed, there simply isn't one at all. This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties. There are still some corner cases that would be nice to solve too (i.e. the Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!
2013-07-07 12:53:15 +00:00
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
}
Fix T103719: missing shortcuts info for some tool-settings Tool settings can be accessed from both `tool_settings` & `scene.tool_settings`. As of [0] `scene.tool_settings` was used instead of `tool_settings` causing the snap shortcut not to display. Resolve by supporting variations of data-paths so both are detected. [0]: 9a76dd2454c2d6f84e4f15c0235669b317599fbd
2023-01-11 20:55:33 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return std::nullopt;
Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these up in the userprefs/keymaps editor, it is quite tricky doing so, and most users would just assume that since no shortcut is displayed, there simply isn't one at all. This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties. There are still some corner cases that would be nice to solve too (i.e. the Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!
2013-07-07 12:53:15 +00:00
}
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
/** \} */
Cleanup: use doxygen sections
2023-03-29 14:16:29 +11:00
/* -------------------------------------------------------------------- */
/** \name Pie Menu Direction
*
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* This goes in a seemingly weird pattern:
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
*
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* <pre>
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
* 4
* 5 6
* 1 2
* 7 8
* 3
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* </pre>
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 it's actually quite logical. It's designed to be 'upwards compatible'
* for muscle memory so that the menu item locations are fixed and don't move
Cleanup: comment spelling
2019-06-16 13:37:21 +10:00
* as new items are added to the menu later on. It also optimizes efficiency -
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
* a radial menu is best kept symmetrical, with as large an angle between
* items as possible, so that the gestural mouse movements can be fast and inexact.
Cleanup: comment blocks
2016-07-15 02:36:21 +10:00
*
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
* It starts off with two opposite sides for the first two items
* then joined by the one below for the third (this way, even with three items,
* the menu seems to still be 'in order' reading left to right). Then the fourth is
* added to complete the compass directions. From here, it's just a matter of
* subdividing the rest of the angles for the last 4 items.
*
* --Matt 07/2006
Cleanup: use doxygen sections
2023-03-29 14:16:29 +11:00
* \{ */
Cleanup: add trailing commas to avoid right shift
2019-04-18 17:17:32 +02:00
const char ui_radial_dir_order[8] = {
UI_RADIAL_W,
UI_RADIAL_E,
UI_RADIAL_S,
UI_RADIAL_N,
UI_RADIAL_NW,
UI_RADIAL_NE,
UI_RADIAL_SW,
UI_RADIAL_SE,
};
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
const char ui_radial_dir_to_numpad[8] = {8, 9, 6, 3, 2, 1, 4, 7};
Maybe slightly controversial pie commit: Make pie menu item placement touch the radius from the internal side of the buttons rather than placing on the center on the cirtcle. This allows us to get rid of the separate visual angle property, also allows for tighter placement of pies with a smaller radius without easily overlapping. Also pie menu title now always appears above the threshold indicator.
2014-08-13 15:11:19 +02:00
const short ui_radial_dir_to_angle[8] = {90, 45, 0, 315, 270, 225, 180, 135};
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
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
static std::string ui_but_pie_direction_string(const uiBut *but)
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
{
BLI_assert(but->pie_dir < ARRAY_SIZE(ui_radial_dir_to_numpad));
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return fmt::to_string(int(ui_radial_dir_to_numpad[but->pie_dir]));
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
}
Cleanup: use doxygen sections
2023-03-29 14:16:29 +11:00
/** \} */
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
static void ui_menu_block_set_keymaps(const bContext *C, uiBlock *block)
{
UI: show toolbar shortcuts When toobar text is expanded, show shortcuts (normally confined to menus).
2018-05-13 10:25:18 +02:00
BLI_assert(block->flag & (UI_BLOCK_LOOP | UI_BLOCK_SHOW_SHORTCUT_ALWAYS));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
/* only do it before bounding */
Splash: add first time setup and templates to splash screen. The first time setup screen only has the interaction preset currently, some more work is needed to be able to set e.g. the language or compute device here as in the mockups. The splash screen stayed the same for now, to make room for the templates most of the links are now in the Help menu. If there are no recent files yet the links still show. The splash screen buttons implementation was fully moved to Python, in the WM_MT_splash menu.
2018-09-18 17:44:14 +02:00
if (block->rect.xmin != block->rect.xmax) {
return;
}
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
if (block->name == "splash") {
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
return;
Splash: add first time setup and templates to splash screen. The first time setup screen only has the interaction preset currently, some more work is needed to be able to set e.g. the language or compute device here as in the mockups. The splash screen stayed the same for now, to make room for the templates most of the links are now in the Help menu. If there are no recent files yet the links still show. The splash screen buttons implementation was fully moved to Python, in the WM_MT_splash menu.
2018-09-18 17:44:14 +02:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
if (block->flag & UI_BLOCK_RADIAL) {
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
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
if (but->pie_dir != UI_RADIAL_NONE) {
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
const std::string str = ui_but_pie_direction_string(but);
ui_but_add_shortcut(but, str.c_str(), false);
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
}
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00: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
}
else {
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: show toolbar shortcuts When toobar text is expanded, show shortcuts (normally confined to menus).
2018-05-13 10:25:18 +02:00
if (block->flag & UI_BLOCK_SHOW_SHORTCUT_ALWAYS) {
/* Skip icon-only buttons (as used in the toolbar). */
if (but->drawstr[0] == '\0') {
continue;
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (((block->flag & UI_BLOCK_POPOVER) == 0) && UI_but_is_tool(but)) {
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* For non-popovers, shown in shortcut only
* (has special shortcut handling code). */
UI: disable key shortcuts for tools Only show shortcuts in the tooltips since they use different logic.
2018-09-03 13:47:14 +10:00
continue;
}
UI: show toolbar shortcuts When toobar text is expanded, show shortcuts (normally confined to menus).
2018-05-13 10:25:18 +02:00
}
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
else if (but->emboss != UI_EMBOSS_PULLDOWN) {
Fix button text overlapping with shortcut text in popups The purpose of the keymap strings is probably for un-embossed menu items like seen in most pulldowns. I can't see a reason for also adding that string for regularly drawn buttons within popups, we don't add it anywhere else in the UI either. So this commit makes sure shortcut strings are only added to buttons that are drawn like pulldown-menu items.
2017-07-27 11:49:41 +02:00
continue;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
if (const std::optional<std::string> str = ui_but_event_operator_string(C, but)) {
ui_but_add_shortcut(but, str->c_str(), false);
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
}
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
else if (const std::optional<std::string> str = ui_but_event_property_operator_string(C,
but))
{
ui_but_add_shortcut(but, str->c_str(), false);
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
}
Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these up in the userprefs/keymaps editor, it is quite tricky doing so, and most users would just assume that since no shortcut is displayed, there simply isn't one at all. This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties. There are still some corner cases that would be nice to solve too (i.e. the Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!
2013-07-07 12:53:15 +00:00
}
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
}
UI: various changes * View2D to region now returns ints instead of shorts. * Use "Numpad" instead of "Pad" in automatic keymap menu info. * Menus can now use buttons other than BUTM and SEPR, in particular TOG and ROW are now supported instead of flipping bits manually. * Added a simpler uiDefMenu* api for making menus now, and it only supports Operator and RNA buttons at the moment, will be used in next commit. Not sure how this will evolve .. makes menu code look cleaner anyways. * Ensure that interface code doesn't crash when getting unknown Operators and RNA properties, and display their buttons grayed out in that case.
2009-01-15 04:13:38 +00:00
}
LibOverride: Fix getting proper RNA path and ID from embedded ones. Master collections and root node trees should now be working as expected in that regard.
2020-07-16 11:03:11 +02:00
void ui_but_override_flag(Main *bmain, uiBut *but)
ID Static Override: add basic UI feedback. For now, using a new color for overridden properties (similar to animated/driven status), UI team will need to work on a better solution maybe...
2017-11-29 15:47:37 +01:00
{
Cleanup: Use unsigned int when for enum values, instead of signed int.
2020-06-30 11:12:09 +02:00
const uint override_status = RNA_property_override_library_status(
LibOverride: Fix getting proper RNA path and ID from embedded ones. Master collections and root node trees should now be working as expected in that regard.
2020-07-16 11:03:11 +02:00
bmain, &but->rnapoin, but->rnaprop, but->rnaindex);
ID Static Override: add basic UI feedback. For now, using a new color for overridden properties (similar to animated/driven status), UI team will need to work on a better solution maybe...
2017-11-29 15:47:37 +01:00
Cleanup: use flags instead of collection of bools to get RNA override status.
2018-03-14 11:47:35 +01:00
if (override_status & RNA_OVERRIDE_STATUS_OVERRIDDEN) {
Cleanup: Typo: `overriden` -> `overridden`.
2020-12-28 10:07:36 +01:00
but->flag |= UI_BUT_OVERRIDDEN;
ID Static Override: add basic UI feedback. For now, using a new color for overridden properties (similar to animated/driven status), UI team will need to work on a better solution maybe...
2017-11-29 15:47:37 +01:00
}
else {
Cleanup: Typo: `overriden` -> `overridden`.
2020-12-28 10:07:36 +01:00
but->flag &= ~UI_BUT_OVERRIDDEN;
ID Static Override: add basic UI feedback. For now, using a new color for overridden properties (similar to animated/driven status), UI team will need to work on a better solution maybe...
2017-11-29 15:47:37 +01:00
}
}
Cleanup: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
/* -------------------------------------------------------------------- */
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
/** \name Button Extra Operator Icons
*
* Extra icons are shown on the right hand side of buttons. They can be clicked to invoke custom
* operators.
* There are some predefined here, which get added to buttons automatically based on button data
* (type, flags, state, etc).
* \{ */
/**
* Predefined types for generic extra operator icons (uiButExtraOpIcon).
*/
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
enum PredefinedExtraOpIconType {
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
PREDEFINED_EXTRA_OP_ICON_NONE = 1,
PREDEFINED_EXTRA_OP_ICON_CLEAR,
PREDEFINED_EXTRA_OP_ICON_EYEDROPPER,
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
};
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
static PointerRNA *ui_but_extra_operator_icon_add_ptr(uiBut *but,
wmOperatorType *optype,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
int icon)
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiButExtraOpIcon *extra_op_icon = MEM_new<uiButExtraOpIcon>(__func__);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
Refactor: Solve invalid icon-id enum values, use type alias Some code attempted to use `BIFIconID` instead of `int` to pass around icon-ids. Problem is, that this is just a subset of the allowed ids, more icons may be created at runtime and extend the range of valid icon-ids. Such icons could give runtime warning prints. Idea is to use a `using BIFIconID = int;` instead. This way there is still a descriptive type name, while the whole dynamic range of possible icon-ids is supported. Additionally multiple `using BIFIconID = int;` declarations are valid, so we can place these in multiple headers and use the type name in APIs instead of just `int`, whithout having to include a single header defining them. A type mismatch (one instance differs from the others) will result in a compiler error. Pull Request: https://projects.blender.org/blender/blender/pulls/111052
2023-08-14 12:06:35 +02:00
extra_op_icon->icon = icon;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
extra_op_icon->optype_params = MEM_cnew<wmOperatorCallParams>(__func__);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
extra_op_icon->optype_params->optype = optype;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
extra_op_icon->optype_params->opptr = MEM_cnew<PointerRNA>(__func__);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
WM_operator_properties_create_ptr(extra_op_icon->optype_params->opptr,
extra_op_icon->optype_params->optype);
extra_op_icon->optype_params->opcontext = opcontext;
UI: Support mouse over highlighting for superimposed icons E.g. the 'x' icons or eyedropper icons in text buttons. They didn't use to have any mouse over feedback, now we dim the icon until hovered. This kind of feedback helps users see that the icons are interactive, and if they are within their interaction hotspot.
2020-09-18 20:10:40 +02:00
extra_op_icon->highlighted = false;
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
extra_op_icon->disabled = false;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
BLI_addtail(&but->extra_op_icons, extra_op_icon);
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
return extra_op_icon->optype_params->opptr;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
}
static void ui_but_extra_operator_icon_free(uiButExtraOpIcon *extra_icon)
{
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
WM_operator_properties_free(extra_icon->optype_params->opptr);
MEM_freeN(extra_icon->optype_params->opptr);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
MEM_freeN(extra_icon->optype_params);
MEM_freeN(extra_icon);
}
void ui_but_extra_operator_icons_free(uiBut *but)
{
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH_MUTABLE (uiButExtraOpIcon *, op_icon, &but->extra_op_icons) {
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
ui_but_extra_operator_icon_free(op_icon);
}
BLI_listbase_clear(&but->extra_op_icons);
}
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
PointerRNA *UI_but_extra_operator_icon_add(uiBut *but,
const char *opname,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
int icon)
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
{
wmOperatorType *optype = WM_operatortype_find(opname, false);
UI: Revert design changes to data-block selector for the 2.92 release Partially reverts 2250b5cefee7. Removing the user count and fake user count icons was controversial (which was expected) and there are a few further changes needed, that won't make it in time for the release, see D9946. While there is a design to bring back the user count and fake user indicators, a new design idea was proposed that the UI team wants to follow. This came too late for the 2.92 release, the new design is targeted at the 2.93 release now. Meanwhile, UI team decision was to simply revert the design changes. The new design is being worked on in https://developer.blender.org/T84669. Note that this commit does not revert some internal changes done in 2250b5cefee7. Namely the introduction of `ed_util_ops.c` and data-block operators in there. These will still be needed in the new design.
2021-01-13 15:08:09 +01:00
if (optype) {
return ui_but_extra_operator_icon_add_ptr(but, optype, opcontext, icon);
}
UI: Redesigned data-block selectors The previous design is rather old and has a couple of problems: * Scalability: The current solution of adding little icon buttons next to the data-block name field doesn't scale well. It only works if there's a small number of operations. We need to be able to place more items there for better data-block management. Especially with the introduction of library overrides. * Discoverability: It's not obvious what some of the icons do. They appear and disappear, but it's not obvious why some are available at times and others not. * Unclear Status: Currently their library status (linked, indirectly linked, broken link, library override) isn't really clear. * Unusual behavior: Some of the icon buttons allow Shift or Ctrl clicking to invoke alternative behaviors. This is not a usual pattern in Blender. This patch does the following changes: * Adds a menu to the right of the name button to access all kinds of operations (create, delete, unlink, user management, library overrides, etc). * Make good use of the "disabled hint" for tooltips, to explain why buttons are disabled. The UI team wants to establish this as a good practise. * Use superimposed icons for duplicate and unlink, rather than extra buttons (uses less space, looks less distracting and is a nice + consistent design language). * Remove fake user and user count button, they are available from the menu now. * Support tooltips for superimposed icons (committed mouse hover feedback to master already). * Slightly increase size of the name button - it was already a bit small before, and the move from real buttons to superimposed icons reduces usable space for the name itself. * More clearly differentiate between duplicate and creating a new data-block. The latter is only available in the menu. * Display library status icon on the left (linked, missing library, overridden, asset) * Disables "Make Single User" button - in review we weren't sure if there are good use-cases for it, so better to see if we can remove it. Note that I do expect some aspects of this design to change still. I think some changes are problematic, but others disagreed. I will open a feedback thread on devtalk to see what others think. Differential Revision: https://developer.blender.org/D8554 Reviewed by: Bastien Montagne Design discussed and agreed on with the UI team, also see T79959.
2020-12-18 18:12:11 +01:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
wmOperatorType *UI_but_extra_operator_icon_optype_get(const uiButExtraOpIcon *extra_icon)
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return extra_icon ? extra_icon->optype_params->optype : nullptr;
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
PointerRNA *UI_but_extra_operator_icon_opptr_get(const uiButExtraOpIcon *extra_icon)
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
{
return extra_icon->optype_params->opptr;
}
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
static bool ui_but_icon_extra_is_visible_text_clear(const uiBut *but)
{
BLI_assert(but->type == UI_BTYPE_TEXT);
return ((but->flag & UI_BUT_VALUE_CLEAR) && but->drawstr[0]);
}
static bool ui_but_icon_extra_is_visible_search_unlink(const uiBut *but)
{
BLI_assert(ELEM(but->type, UI_BTYPE_SEARCH_MENU));
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return ((but->editstr == nullptr) && (but->drawstr[0] != '\0') &&
(but->flag & UI_BUT_VALUE_CLEAR));
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
}
static bool ui_but_icon_extra_is_visible_search_eyedropper(uiBut *but)
{
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU && (but->flag & UI_BUT_VALUE_CLEAR));
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->rnaprop == nullptr) {
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
return false;
}
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
StructRNA *type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const short idcode = RNA_type_to_ID_code(type);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return ((but->editstr == nullptr) && (idcode == ID_OB || OB_DATA_SUPPORT_ID(idcode)));
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
}
static PredefinedExtraOpIconType ui_but_icon_extra_get(uiBut *but)
{
switch (but->type) {
case UI_BTYPE_TEXT:
if (ui_but_icon_extra_is_visible_text_clear(but)) {
return PREDEFINED_EXTRA_OP_ICON_CLEAR;
}
break;
case UI_BTYPE_SEARCH_MENU:
if ((but->flag & UI_BUT_VALUE_CLEAR) == 0) {
/* pass */
}
else if (ui_but_icon_extra_is_visible_search_unlink(but)) {
return PREDEFINED_EXTRA_OP_ICON_CLEAR;
}
else if (ui_but_icon_extra_is_visible_search_eyedropper(but)) {
return PREDEFINED_EXTRA_OP_ICON_EYEDROPPER;
}
break;
default:
break;
}
return PREDEFINED_EXTRA_OP_ICON_NONE;
}
/**
* While some extra operator icons have to be set explicitly upon button creating, this code adds
* some generic ones based on button data. Currently these are mutually exclusive, so there's only
* ever one predefined extra icon.
*/
static void ui_but_predefined_extra_operator_icons_add(uiBut *but)
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const PredefinedExtraOpIconType extra_icon = ui_but_icon_extra_get(but);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmOperatorType *optype = nullptr;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
BIFIconID icon = ICON_NONE;
switch (extra_icon) {
case PREDEFINED_EXTRA_OP_ICON_EYEDROPPER: {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
static wmOperatorType *id_eyedropper_ot = nullptr;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
if (!id_eyedropper_ot) {
id_eyedropper_ot = WM_operatortype_find("UI_OT_eyedropper_id", false);
}
BLI_assert(id_eyedropper_ot);
optype = id_eyedropper_ot;
icon = ICON_EYEDROPPER;
break;
}
case PREDEFINED_EXTRA_OP_ICON_CLEAR: {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
static wmOperatorType *clear_ot = nullptr;
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
if (!clear_ot) {
clear_ot = WM_operatortype_find("UI_OT_button_string_clear", false);
}
BLI_assert(clear_ot);
optype = clear_ot;
icon = ICON_PANEL_CLOSE;
break;
}
default:
break;
}
if (optype) {
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiButExtraOpIcon *, op_icon, &but->extra_op_icons) {
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
if ((op_icon->optype_params->optype == optype) && (op_icon->icon == icon)) {
/* Don't add the same operator icon twice (happens if button is kept alive while active).
*/
return;
}
}
Refactor: Solve invalid icon-id enum values, use type alias Some code attempted to use `BIFIconID` instead of `int` to pass around icon-ids. Problem is, that this is just a subset of the allowed ids, more icons may be created at runtime and extend the range of valid icon-ids. Such icons could give runtime warning prints. Idea is to use a `using BIFIconID = int;` instead. This way there is still a descriptive type name, while the whole dynamic range of possible icon-ids is supported. Additionally multiple `using BIFIconID = int;` declarations are valid, so we can place these in multiple headers and use the type name in APIs instead of just `int`, whithout having to include a single header defining them. A type mismatch (one instance differs from the others) will result in a compiler error. Pull Request: https://projects.blender.org/blender/blender/pulls/111052
2023-08-14 12:06:35 +02:00
ui_but_extra_operator_icon_add_ptr(but, optype, WM_OP_INVOKE_DEFAULT, icon);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
}
}
/** \} */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_update_from_old(const bContext *C, 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
{
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (!block->oldblock) {
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
return;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *but_old = static_cast<uiBut *>(block->oldblock->buttons.first);
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
if (BLI_listbase_is_empty(&block->oldblock->butstore) == false) {
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
UI_butstore_update(block);
}
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
if (ui_but_update_from_old_block(C, block, &but, &but_old)) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
UI: update dynamic tips Useful for progress ETA to continuously update. This adds API option not to activate new regions GL state which isn't needed in many cases.
2016-02-02 14:13:57 +11:00
/* redraw dynamic tooltip if we have one open */
if (but->tip_func) {
UI_but_tooltip_refresh((bContext *)C, but);
}
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
}
}
block->auto_open = block->oldblock->auto_open;
block->auto_open_last = block->oldblock->auto_open_last;
block->tooltipdisabled = block->oldblock->tooltipdisabled;
Fix T42208 color pickers are coupled. Decouple color picker hsv data from the whole block. Basically, each color picker now takes care of creating its own color picker role. For this bug report it can be seen that probably HSV is not the best space for gamma/lift/gain workflow because it is bounded at 1.0 but this is a separate issue.
2014-11-06 20:19:21 +01:00
BLI_movelisttolist(&block->color_pickers.list, &block->oldblock->color_pickers.list);
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
block->oldblock = nullptr;
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
}
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
#ifndef NDEBUG
/**
* Extra sanity checks for invariants (debug builds only).
*/
static void ui_but_validate(const uiBut *but)
{
/* Number buttons must have a click-step,
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
* assert instead of correcting the value to ensure the caller knows what they're doing. */
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
if (but->type == UI_BTYPE_NUM) {
uiButNumber *number_but = (uiButNumber *)but;
if (ELEM(but->pointype, UI_BUT_POIN_CHAR, UI_BUT_POIN_SHORT, UI_BUT_POIN_INT)) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
BLI_assert(int(number_but->step_size) > 0);
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
}
}
}
#endif
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
bool ui_but_context_poll_operator_ex(bContext *C,
const uiBut *but,
const wmOperatorCallParams *optype_params)
Cleanup: Move button context based operator poll into utility function Using the button context for operators is useful for other cases as well (where the operator isn't the button operator itself). For example we'll need this for the asset view UI template, where there will be additional operators that should be able to act on button context.
2021-03-24 14:05:57 +01:00
{
bool result;
Fix T97518: All buttons with eyedropper highlight if one is hovered Issue is that the operator acts on the active button, and also uses that in the poll. So the actually active button would affect the poll of a different button. For the superimposed icons we need to be able to execute these polls properly for non-active buttons. This enables temporarily overriding the active button for lookups via context. While a bit of a hack it makes sense conceptually. Reviewed By: Campbell Barton Maniphest Tasks: T97518 Differential Revision: https://developer.blender.org/D14880
2022-05-13 15:55:11 +02:00
int old_but_flag = 0;
Cleanup: Move button context based operator poll into utility function Using the button context for operators is useful for other cases as well (where the operator isn't the button operator itself). For example we'll need this for the asset view UI template, where there will be additional operators that should be able to act on button context.
2021-03-24 14:05:57 +01:00
Fix T97518: All buttons with eyedropper highlight if one is hovered Issue is that the operator acts on the active button, and also uses that in the poll. So the actually active button would affect the poll of a different button. For the superimposed icons we need to be able to execute these polls properly for non-active buttons. This enables temporarily overriding the active button for lookups via context. While a bit of a hack it makes sense conceptually. Reviewed By: Campbell Barton Maniphest Tasks: T97518 Differential Revision: https://developer.blender.org/D14880
2022-05-13 15:55:11 +02:00
if (but) {
old_but_flag = but->flag;
/* Temporarily make this button override the active one, in case the poll acts on the active
* button. */
const_cast<uiBut *>(but)->flag |= UI_BUT_ACTIVE_OVERRIDE;
if (but->context) {
CTX_store_set(C, but->context);
}
Cleanup: Move button context based operator poll into utility function Using the button context for operators is useful for other cases as well (where the operator isn't the button operator itself). For example we'll need this for the asset view UI template, where there will be additional operators that should be able to act on button context.
2021-03-24 14:05:57 +01:00
}
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
result = WM_operator_poll_context(C, optype_params->optype, optype_params->opcontext);
Cleanup: Move button context based operator poll into utility function Using the button context for operators is useful for other cases as well (where the operator isn't the button operator itself). For example we'll need this for the asset view UI template, where there will be additional operators that should be able to act on button context.
2021-03-24 14:05:57 +01:00
Fix T97518: All buttons with eyedropper highlight if one is hovered Issue is that the operator acts on the active button, and also uses that in the poll. So the actually active button would affect the poll of a different button. For the superimposed icons we need to be able to execute these polls properly for non-active buttons. This enables temporarily overriding the active button for lookups via context. While a bit of a hack it makes sense conceptually. Reviewed By: Campbell Barton Maniphest Tasks: T97518 Differential Revision: https://developer.blender.org/D14880
2022-05-13 15:55:11 +02:00
if (but) {
BLI_assert_msg((but->flag & ~UI_BUT_ACTIVE_OVERRIDE) ==
(old_but_flag & ~UI_BUT_ACTIVE_OVERRIDE),
"Operator polls shouldn't change button flags");
const_cast<uiBut *>(but)->flag = old_but_flag;
if (but->context) {
CTX_store_set(C, nullptr);
}
Cleanup: Move button context based operator poll into utility function Using the button context for operators is useful for other cases as well (where the operator isn't the button operator itself). For example we'll need this for the asset view UI template, where there will be additional operators that should be able to act on button context.
2021-03-24 14:05:57 +01:00
}
return result;
}
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
bool ui_but_context_poll_operator(bContext *C, wmOperatorType *ot, const uiBut *but)
{
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
const wmOperatorCallContext opcontext = but ? but->opcontext : WM_OP_INVOKE_DEFAULT;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmOperatorCallParams params = {};
params.optype = ot;
params.opcontext = opcontext;
return ui_but_context_poll_operator_ex(C, but, &params);
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
}
Fix T52999: floating (popup) panels/menus could jump around screen in some cases. Would happen during panel's refresh drawing, if drawing code had to adjust final panel position compared to the initial one computed based on the mouse coordinates, and user had dragged the floating panel around. Issue fixed by adjusting stored mouse coordinates once final panel position is known, such that they would directly generate those coordinates. that way, the basic offset applied to those stored mouse coordinates during panel dragging is valid, and recreating panel based on those won't make it jump in screen. Note that panel will still jump in case user dragged it partially out of view - we could prevent that, but imho it's better to keep that behavior, since redraw can generate a popup of different size, which could end up with a totally out-of-view one... Hopefully this fix does not break anything else!
2017-10-12 14:43:45 +02:00
void UI_block_end_ex(const bContext *C, uiBlock *block, const int xy[2], int r_xy[2])
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
{
wmWindow *window = CTX_wm_window(C);
Scene *scene = CTX_data_scene(C);
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
ARegion *region = CTX_wm_region(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
Depsgraph *depsgraph = CTX_data_depsgraph_pointer(C);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
BLI_assert(block->active);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Support mouse over highlighting for superimposed icons E.g. the 'x' icons or eyedropper icons in text buttons. They didn't use to have any mouse over feedback, now we dim the icon until hovered. This kind of feedback helps users see that the icons are interactive, and if they are within their interaction hotspot.
2020-09-18 20:10:40 +02:00
/* Extend button data. This needs to be done before the block updating. */
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
ui_but_predefined_extra_operator_icons_add(but);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_update_from_old(C, block);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* inherit flags from 'old' buttons that was drawn here previous, based
* on matching buttons, we need this to make button event handling non
spelling corrections in comments and quiet warning
2011-10-15 14:14:22 +00:00
* blocking, while still allowing buttons to be remade each redraw as it
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
* is expected by blender code */
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
More spell and typo fixes (mostly visualise->visualize, grey->gray, normalise->normalize).
2012-07-03 19:09:07 +00:00
/* temp? Proper check for graying out */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->optype) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmOperatorType *ot = but->optype;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (ot == nullptr || !ui_but_context_poll_operator((bContext *)C, ot, but)) {
2.5 Cleanup of saving code for Image window. Little extra: added poll() check for buttons, greying out inactive menu items or buttons. You can see it work in Image menu. (Item 'save image' is grey when it wasn't saved, then you have to use the 'save as' item). Carefully designing poll checks is worth a trial once. :) Do note that cpu time for polls should be totally minimal.
2009-02-18 18:08:33 +00:00
but->flag |= UI_BUT_DISABLED;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: Support showing superimposed icons as disabled (with disabled hint) If the operator poll of a superimposed icon returned `false`, the superimposed icon would just draw normally and fail silently. Instead it will now be drawn grayed out, plus the tooltip of the icon can show the usual "disabled hint" (a hint explaining why the button is disabled).
2021-10-08 16:17:29 +02:00
LISTBASE_FOREACH (uiButExtraOpIcon *, op_icon, &but->extra_op_icons) {
if (!ui_but_context_poll_operator_ex((bContext *)C, but, op_icon->optype_params)) {
op_icon->disabled = true;
}
}
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
const AnimationEvalContext anim_eval_context = BKE_animsys_eval_context_construct(
depsgraph, (scene) ? scene->r.cfra : 0.0f);
ui_but_anim_flag(but, &anim_eval_context);
LibOverride: Fix getting proper RNA path and ID from embedded ones. Master collections and root node trees should now be working as expected in that regard.
2020-07-16 11:03:11 +02:00
ui_but_override_flag(CTX_data_main(C), but);
UI: show decorator icon for static-override
2018-06-16 18:26:34 +02:00
if (UI_but_is_decorator(but)) {
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
ui_but_anim_decorate_update_from_flag((uiButDecorator *)but);
2.5 Cleanup of saving code for Image window. Little extra: added poll() check for buttons, greying out inactive menu items or buttons. You can see it work in Image menu. (Item 'save image' is grey when it wasn't saved, then you have to use the 'save as' item). Carefully designing poll checks is worth a trial once. :) Do note that cpu time for polls should be totally minimal.
2009-02-18 18:08:33 +00:00
}
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
#ifndef NDEBUG
ui_but_validate(but);
#endif
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* handle pending stuff */
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
if (block->layouts.first) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
UI_block_layout_resolve(block, nullptr, nullptr);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
}
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
ui_block_align_calc(block, CTX_wm_region(C));
UI: support searching in menus The basic idea is very simple. Whenever a supported menu is open, one can just start typing and this opens a search that contains all the (nested) menu entries. The main downside is that this collides with accelerator keys. Those are the underlined characters in each menu. For now, we just enable this new searching behavior in a few selected menus: Node Add Menu, View3D Add Menu and Modifier Add Menu. This new functionality can be enabled for a menu by setting `bl_options = {'SEARCH_ON_KEY_PRESS'}` to true in the menu type. The status bar shows `Type to search...` when a menu is opened that supports search. Pull Request: https://projects.blender.org/blender/blender/pulls/110855
2023-09-06 18:16:45 +02:00
if ((block->flag & UI_BLOCK_LOOP) && (block->flag & UI_BLOCK_NUMSELECT) &&
(block->flag & UI_BLOCK_NO_ACCELERATOR_KEYS) == 0)
{
split >120 length lines (mostly if statements)
2011-12-22 00:03:20 +00:00
ui_menu_block_set_keyaccels(block); /* could use a different flag to check */
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: show toolbar shortcuts When toobar text is expanded, show shortcuts (normally confined to menus).
2018-05-13 10:25:18 +02:00
if (block->flag & (UI_BLOCK_LOOP | UI_BLOCK_SHOW_SHORTCUT_ALWAYS)) {
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
ui_menu_block_set_keymaps(C, block);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
/* after keymaps! */
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
switch (block->bounds_type) {
case UI_BLOCK_BOUNDS_NONE:
break;
case UI_BLOCK_BOUNDS:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc(block);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
break;
case UI_BLOCK_BOUNDS_TEXT:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc_text(block, 0.0f);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
break;
case UI_BLOCK_BOUNDS_POPUP_CENTER:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc_centered(window, block);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
break;
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
case UI_BLOCK_BOUNDS_PIE_CENTER:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_block_bounds_calc_centered_pie(block);
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
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
/* fallback */
case UI_BLOCK_BOUNDS_POPUP_MOUSE:
case UI_BLOCK_BOUNDS_POPUP_MENU:
Fix T52999: floating (popup) panels/menus could jump around screen in some cases. Would happen during panel's refresh drawing, if drawing code had to adjust final panel position compared to the initial one computed based on the mouse coordinates, and user had dragged the floating panel around. Issue fixed by adjusting stored mouse coordinates once final panel position is known, such that they would directly generate those coordinates. that way, the basic offset applied to those stored mouse coordinates during panel dragging is valid, and recreating panel based on those won't make it jump in screen. Note that panel will still jump in case user dragged it partially out of view - we could prevent that, but imho it's better to keep that behavior, since redraw can generate a popup of different size, which could end up with a totally out-of-view one... Hopefully this fix does not break anything else!
2017-10-12 14:43:45 +02:00
ui_block_bounds_calc_popup(window, block, block->bounds_type, xy, r_xy);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
break;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix UI view drag target not using correct boundaries with panels Initial idea was to calculate the view boundaries when finishing the `uiBlock`, after layout code and such ran. But the panel code applies an offset later, which breaks this. The view boundaries would be off by something like 100px.
2023-03-24 11:37:40 +01:00
/* Update bounds of all views in this block. If this block is a panel, this will be done later in
* #UI_panels_end(), because buttons are offset there. */
if (!block->panel) {
ui_block_views_bounds_calc(block);
}
UI: Generalize drop target API, support drop targets for UI views Previously UI view items would support custom drop controllers (so they could react to data being dragged over them and dropped). This is now more generalized so the views themselves can do this as well. Main changes: - Support calculating a bounding box for the view, so this can be used for recognizing mouse hovering. - Rename "drop controller" to "drop target", this is more clear, less abstract naming. - Generalize drop controllers/targets. There is a new `ui::DropTargetInterface` now. - Add support for drop targets in the `ui::AbstractView` base class, so custom views can use this. Pull Request: https://projects.blender.org/blender/blender/pulls/105963
2023-03-22 18:45:35 +01:00
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
if (block->rect.xmin == 0.0f && block->rect.xmax == 0.0f) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_bounds_set_normal(block, 0);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
}
if (block->flag & UI_BUT_ALIGN) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_align_end(block);
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
ui_update_flexible_spacing(region, block);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Use bool instead of char
2021-02-22 13:18:49 -06:00
block->endblock = true;
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_end(const bContext *C, uiBlock *block)
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
{
wmWindow *window = CTX_wm_window(C);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
UI_block_end_ex(C, block, window->eventstate->xy, nullptr);
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* ************** BLOCK DRAWING FUNCTION ************* */
BLF: Use Floats for Font Point Sizes Allow the use of floating-point values for font point sizes, which allows greater precision and flexibility for text output. See D8960 for more information, details, and justification. Differential Revision: https://developer.blender.org/D8960 Reviewed by Campbell Barton
2021-11-13 09:39:18 -08:00
void ui_fontscale(float *points, float aspect)
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
{
BLF: Use Floats for Font Point Sizes Allow the use of floating-point values for font point sizes, which allows greater precision and flexibility for text output. See D8960 for more information, details, and justification. Differential Revision: https://developer.blender.org/D8960 Reviewed by Campbell Barton
2021-11-13 09:39:18 -08:00
*points /= aspect;
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
}
UI: Draw hierarchy lines for tree-views Hierarchy lines (like we also have in the Outliner) make it easier to visually parse the hierarchy, and avoid confusion about nesting level. Especially when some items have icons and/or collapse chevrons and some not (thus different levels of visual indentation). They were planned for #93582 and #107881, also see https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#layer-groups. The drawing is implemented as a general tree-view feature, so all tree-views with collapsable items (which excludes the spreadsheet data-set tree view) will get them without further setup.
2023-07-06 17:00:44 +02:00
void ui_but_to_pixelrect(rcti *rect, const ARegion *region, const uiBlock *block, const uiBut *but)
2.5 WIP commit for UI drawing. - Hooked up Diego's new Font API - Added Style definitions for fonts, currently it uses a different font for panel titles to show it. - Styles are in Userdef now too, still not finished - Userdef "DPI" will offer global control over font size, to match monitor size/resolution. It's meant to scale widgets and headers too btw, later. - Lots of code removed for old fonts, but that's unfinished. On todo: too much to mention, will continue happily tomorrow!
2009-04-09 18:11:18 +00:00
{
UI: add support for uiLayout based panels This adds support for so called "layout panels" which are panels that are created as part of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI. The initial use case for this are panels in the geometry nodes modifier. This patch provides a better solution compared to what was attempted in #108565. ### Problems with Existing Approaches Currently, there are two ways to create these expandable sections: * One can define a new `Panel` type for each expandable section and use the `parent_id` to make this a subpanel of another panel. This has a few problems: * `uiLayout` drawing code is more scattered, because one can't just use a single function that creates the layout for an entire panel including its subpanels. * It does not work so well for dynamic amounts of panels (e.g. like what we need for the geometry nodes modifier to organize the inputs). * Typically, Blender uses a immediate-ui approach, but subpanels break that currently and need extra handling. * The order of panels is not very explicit. * One can't interleave subpanels and other ui elements, subpanels always come at the end of the parent panel. * Custom solution using existing `uiLayout`. This is done in the material properties. It also has a few problems: * Custom solutions tend to work slightly different in different places. So the UI is less unified. * Can't drag open/close multiple panels. * The background color for subpanels does not change. ### Solution A possible solution to all of these problems is to add support for panels to `uiLayout` directly: ```cpp /* Add elements before subpanel. */ if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) { /* Add elements in subpanel, but only of the panel is open. */ } /* Add elements after subpanel. */ ``` Integrating subpanels with `uiLayout` has some benefits: * Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate. * It becomes trivial to have a dynamic number of potentially nested subpanels. * Resolves all mentioned problems of custom subpanel solutions. ### Open/Close State The most tricky thing is to decide where to store the open/close state. Ideally, it should be stored in the `region` because then the same layout panel can be opened and closed in every region independently. Unfortunately, storing the state in the region is fairly complex in some cases. For example, for modifier subpanels the region would have to store an open/close state for each panel in each modifier in each object. So a map with `object pointer + modifier id + panel id` as key would be required. Obviously, this map could become quite big. Also storing that many ID pointers in UI data is not great and we don't even have stable modifier ids yet. There also isn't an obvious way for how to clear unused elements from the map which could become necessary when it becomes big. In practice, it's rare that the same modifier list is shown in two editors. So the benefit of storing the open/close state in the region is negligible. Therefor, a much simpler solution is possible: the open/close state can be stored in the modifier directly. This is actually how it was implemented before already (see `ui_expand_flag`). The implementation of layout panels in this patch is *agnostic* to how the open/close state is stored exactly, as long as it can be referenced as a boolean rna property. This allows us to store the state in the modifier directly but also allows us to store the state in the region for other layout panels in the future. We could consider adding an API that makes it easy to store the state in the region for cases where the key is simpler. For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`. ### Python API (not included) Adding a Python API is fairly straight forward. However, it is **not** included in this patch so that we can mature the internal API a bit more if necessary, before addon developers start to depend on it. It would probably work like so: ```python if panel := layout.panel("Mesh Settings", ...): # Add layout elements in the panel if it's open. ``` Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
*rect = ui_to_pixelrect(region, block, (but) ? &but->rect : &block->rect);
}
fix [#35346] Python: still UI issue with popup and dropdown list
2013-06-13 09:12:53 +00:00
UI: add support for uiLayout based panels This adds support for so called "layout panels" which are panels that are created as part of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI. The initial use case for this are panels in the geometry nodes modifier. This patch provides a better solution compared to what was attempted in #108565. ### Problems with Existing Approaches Currently, there are two ways to create these expandable sections: * One can define a new `Panel` type for each expandable section and use the `parent_id` to make this a subpanel of another panel. This has a few problems: * `uiLayout` drawing code is more scattered, because one can't just use a single function that creates the layout for an entire panel including its subpanels. * It does not work so well for dynamic amounts of panels (e.g. like what we need for the geometry nodes modifier to organize the inputs). * Typically, Blender uses a immediate-ui approach, but subpanels break that currently and need extra handling. * The order of panels is not very explicit. * One can't interleave subpanels and other ui elements, subpanels always come at the end of the parent panel. * Custom solution using existing `uiLayout`. This is done in the material properties. It also has a few problems: * Custom solutions tend to work slightly different in different places. So the UI is less unified. * Can't drag open/close multiple panels. * The background color for subpanels does not change. ### Solution A possible solution to all of these problems is to add support for panels to `uiLayout` directly: ```cpp /* Add elements before subpanel. */ if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) { /* Add elements in subpanel, but only of the panel is open. */ } /* Add elements after subpanel. */ ``` Integrating subpanels with `uiLayout` has some benefits: * Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate. * It becomes trivial to have a dynamic number of potentially nested subpanels. * Resolves all mentioned problems of custom subpanel solutions. ### Open/Close State The most tricky thing is to decide where to store the open/close state. Ideally, it should be stored in the `region` because then the same layout panel can be opened and closed in every region independently. Unfortunately, storing the state in the region is fairly complex in some cases. For example, for modifier subpanels the region would have to store an open/close state for each panel in each modifier in each object. So a map with `object pointer + modifier id + panel id` as key would be required. Obviously, this map could become quite big. Also storing that many ID pointers in UI data is not great and we don't even have stable modifier ids yet. There also isn't an obvious way for how to clear unused elements from the map which could become necessary when it becomes big. In practice, it's rare that the same modifier list is shown in two editors. So the benefit of storing the open/close state in the region is negligible. Therefor, a much simpler solution is possible: the open/close state can be stored in the modifier directly. This is actually how it was implemented before already (see `ui_expand_flag`). The implementation of layout panels in this patch is *agnostic* to how the open/close state is stored exactly, as long as it can be referenced as a boolean rna property. This allows us to store the state in the modifier directly but also allows us to store the state in the region for other layout panels in the future. We could consider adding an API that makes it easy to store the state in the region for cases where the key is simpler. For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`. ### Python API (not included) Adding a Python API is fairly straight forward. However, it is **not** included in this patch so that we can mature the internal API a bit more if necessary, before addon developers start to depend on it. It would probably work like so: ```python if panel := layout.panel("Mesh Settings", ...): # Add layout elements in the panel if it's open. ``` Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
rcti ui_to_pixelrect(const ARegion *region, const uiBlock *block, const rctf *src_rect)
{
rctf rectf;
ui_block_to_window_rctf(region, block, &rectf, src_rect);
rcti recti;
BLI_rcti_rctf_copy_round(&recti, &rectf);
BLI_rcti_translate(&recti, -region->winrct.xmin, -region->winrct.ymin);
return recti;
2.5 WIP commit for UI drawing. - Hooked up Diego's new Font API - Added Style definitions for fonts, currently it uses a different font for panel titles to show it. - Styles are in Userdef now too, still not finished - Userdef "DPI" will offer global control over font size, to match monitor size/resolution. It's meant to scale widgets and headers too btw, later. - Lots of code removed for old fonts, but that's unfinished. On todo: too much to mention, will continue happily tomorrow!
2009-04-09 18:11:18 +00:00
}
UI: (Performance) Avoid drawing buttons out of view The UI was always drawing all buttons in a layout, no matter if they were scrolled out of view (as in, outside of the visible part of the region) or not. This means it's doing quite some work that can be avoided. UI drawing generally isn't a big bottleneck in Blender, so I don't expect huge speedups from this. But while playing back animation, we do redraw a fair bit of the UI, so in cases where there are many buttons out of view, it may bring a little FPS boost. E.g. say in complex node trees (the node editor is redrawn on animation playback in case there are animated values that need updated UI feedback). This also mitigates the issue in T92922 significantly. Differential Revision: https://developer.blender.org/T92922 Reviewed by: Brecht Van Lommel
2021-11-12 18:16:18 +01:00
static bool ui_but_pixelrect_in_view(const ARegion *region, const rcti *rect)
{
rcti rect_winspace = *rect;
BLI_rcti_translate(&rect_winspace, region->winrct.xmin, region->winrct.ymin);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return BLI_rcti_isect(&region->winrct, &rect_winspace, nullptr);
UI: (Performance) Avoid drawing buttons out of view The UI was always drawing all buttons in a layout, no matter if they were scrolled out of view (as in, outside of the visible part of the region) or not. This means it's doing quite some work that can be avoided. UI drawing generally isn't a big bottleneck in Blender, so I don't expect huge speedups from this. But while playing back animation, we do redraw a fair bit of the UI, so in cases where there are many buttons out of view, it may bring a little FPS boost. E.g. say in complex node trees (the node editor is redrawn on animation playback in case there are animated values that need updated UI feedback). This also mitigates the issue in T92922 significantly. Differential Revision: https://developer.blender.org/T92922 Reviewed by: Brecht Van Lommel
2021-11-12 18:16:18 +01:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_draw(const bContext *C, 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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiStyle style = *UI_style_get_dpi(); /* XXX pass on as arg */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: * Screen level regions created for menus are now a separate CTX_wm_menu in the context, so they don't interfere with existing regions. * Fix context in popup menus to always come from the area and region the popup was opened from. * Removed some unused context stuff: tasks and reports. The places that were using context reports were using it wrong anyway. * Fix F6 closing immediately after editing a button, by making uiBlockSetFlag not clear existing flags anymore. * Don't use ":" in boolean X/Y/Z buttons.
2009-03-25 20:49:15 +00:00
/* get menu region or area region */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
ARegion *region = CTX_wm_menu(C);
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
if (!region) {
region = CTX_wm_region(C);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (!block->endblock) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_end(C, block);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* we set this only once */
GPUState: GPU_blend final API renaming We now use GPU_blend for enabling / disabling blending and explicitly set the blend equation.
2020-08-16 15:38:34 +02:00
GPU_blend(GPU_BLEND_ALPHA);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
/* scale fonts */
ui_fontscale(&style.paneltitle.points, block->aspect);
ui_fontscale(&style.grouplabel.points, block->aspect);
ui_fontscale(&style.widgetlabel.points, block->aspect);
ui_fontscale(&style.widget.points, block->aspect);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
/* scale block min/max to rect */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
rcti rect;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
ui_but_to_pixelrect(&rect, region, block, nullptr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 - Widgets now draw projected themselves, putting window/region matrix on 1:1 pixelspace. This allows zoomable buttons, but crispy. - Note: text in smaller buttons dont get clipped correct now, WIP - Fixed error with button types in some menus. - removed temp UI_2_50 define hack.
2009-04-07 17:08:26 +00:00
/* pixel space for AA widgets */
GPU_matrix: use Blender's naming conventions Thanks to @sergey for review
2018-07-15 15:27:15 +02:00
GPU_matrix_push_projection();
GPU_matrix_push();
GPU_matrix_identity_set();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
wmOrtho2_region_pixelspace(region);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 WIP commit for UI drawing. - Hooked up Diego's new Font API - Added Style definitions for fonts, currently it uses a different font for panel titles to show it. - Styles are in Userdef now too, still not finished - Userdef "DPI" will offer global control over font size, to match monitor size/resolution. It's meant to scale widgets and headers too btw, later. - Lots of code removed for old fonts, but that's unfinished. On todo: too much to mention, will continue happily tomorrow!
2009-04-09 18:11:18 +00:00
/* back */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block->flag & UI_BLOCK_RADIAL) {
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
ui_draw_pie_center(block);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (block->flag & UI_BLOCK_POPOVER) {
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_draw_popover_back(region, &style, block, &rect);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (block->flag & UI_BLOCK_LOOP) {
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
ui_draw_menu_back(&style, block, &rect);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: use popup draw style for redo panel
2018-09-11 11:22:08 +10:00
else if (block->panel) {
UI: add support for uiLayout based panels This adds support for so called "layout panels" which are panels that are created as part of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI. The initial use case for this are panels in the geometry nodes modifier. This patch provides a better solution compared to what was attempted in #108565. ### Problems with Existing Approaches Currently, there are two ways to create these expandable sections: * One can define a new `Panel` type for each expandable section and use the `parent_id` to make this a subpanel of another panel. This has a few problems: * `uiLayout` drawing code is more scattered, because one can't just use a single function that creates the layout for an entire panel including its subpanels. * It does not work so well for dynamic amounts of panels (e.g. like what we need for the geometry nodes modifier to organize the inputs). * Typically, Blender uses a immediate-ui approach, but subpanels break that currently and need extra handling. * The order of panels is not very explicit. * One can't interleave subpanels and other ui elements, subpanels always come at the end of the parent panel. * Custom solution using existing `uiLayout`. This is done in the material properties. It also has a few problems: * Custom solutions tend to work slightly different in different places. So the UI is less unified. * Can't drag open/close multiple panels. * The background color for subpanels does not change. ### Solution A possible solution to all of these problems is to add support for panels to `uiLayout` directly: ```cpp /* Add elements before subpanel. */ if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) { /* Add elements in subpanel, but only of the panel is open. */ } /* Add elements after subpanel. */ ``` Integrating subpanels with `uiLayout` has some benefits: * Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate. * It becomes trivial to have a dynamic number of potentially nested subpanels. * Resolves all mentioned problems of custom subpanel solutions. ### Open/Close State The most tricky thing is to decide where to store the open/close state. Ideally, it should be stored in the `region` because then the same layout panel can be opened and closed in every region independently. Unfortunately, storing the state in the region is fairly complex in some cases. For example, for modifier subpanels the region would have to store an open/close state for each panel in each modifier in each object. So a map with `object pointer + modifier id + panel id` as key would be required. Obviously, this map could become quite big. Also storing that many ID pointers in UI data is not great and we don't even have stable modifier ids yet. There also isn't an obvious way for how to clear unused elements from the map which could become necessary when it becomes big. In practice, it's rare that the same modifier list is shown in two editors. So the benefit of storing the open/close state in the region is negligible. Therefor, a much simpler solution is possible: the open/close state can be stored in the modifier directly. This is actually how it was implemented before already (see `ui_expand_flag`). The implementation of layout panels in this patch is *agnostic* to how the open/close state is stored exactly, as long as it can be referenced as a boolean rna property. This allows us to store the state in the modifier directly but also allows us to store the state in the region for other layout panels in the future. We could consider adding an API that makes it easy to store the state in the region for cases where the key is simpler. For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`. ### Python API (not included) Adding a Python API is fairly straight forward. However, it is **not** included in this patch so that we can mature the internal API a bit more if necessary, before addon developers start to depend on it. It would probably work like so: ```python if panel := layout.panel("Mesh Settings", ...): # Add layout elements in the panel if it's open. ``` Pull Request: https://projects.blender.org/blender/blender/pulls/113584
2023-12-22 17:57:57 +01:00
ui_draw_aligned_panel(region,
&style,
UI: Single tab property search This adds a search bar to the properties editor. The full search for every tab isn't included in this patch, but the interaction with panels, searching behavior, UI, region level, and DNA changes are included here. The block-level search works by iterating over the block's button groups and checking whether they match the search. If they do, they are tagged with a flag, and the block's panel is tagged too. For every update (text edit), the panel's expansion is set to whether the panel has a result or not. The search also checks for matching strings inside enums and in panel labels. One complication to this that isn't immediately apparent is that closed panel's subpanels have to be searched too. This adds some complexity to the area-level panel layout code. Possible Future Improvements: - Use the new fuzzy search in BLI - Reset panels to their expansion before the search started if the user escape out of the text box. - Open all child panels of a panel with expansion. Differential Revision: https://developer.blender.org/D8856
2020-09-15 11:25:49 -05:00
block,
&rect,
UI_panel_category_is_visible(region),
Fix T92313: Heading of redo panel is not aligned properly This corrects some alignments issues through new margins introduced in 93544b641bd6. Basic idea of this fix is to only add the new margins when drawing a panel with background. These margins were added specifically for the background boxes, so that makes sense. Alternative fix to D13199. This also fixes some margings added unintentionally in mentioned commit. There is a little jump of the toolbar and the tabs in the Properties when comparing the UI without this fix to 2.93: {F12158085} {F12158039} The jump is gone with this fix applied (compare to the 2.93 screenshot): {F12158064} While not a serious issue, this confirms that this fix actually tackles the root of the issue.
2021-11-25 16:53:44 +01:00
UI_panel_should_show_background(region, block->panel->type),
UI: Single tab property search This adds a search bar to the properties editor. The full search for every tab isn't included in this patch, but the interaction with panels, searching behavior, UI, region level, and DNA changes are included here. The block-level search works by iterating over the block's button groups and checking whether they match the search. If they do, they are tagged with a flag, and the block's panel is tagged too. For every update (text edit), the panel's expansion is set to whether the panel has a result or not. The search also checks for matching strings inside enums and in panel labels. One complication to this that isn't immediately apparent is that closed panel's subpanels have to be searched too. This adds some complexity to the area-level panel layout code. Possible Future Improvements: - Use the new fuzzy search in BLI - Reset panels to their expansion before the search started if the user escape out of the text box. - Open all child panels of a panel with expansion. Differential Revision: https://developer.blender.org/D8856
2020-09-15 11:25:49 -05:00
region->flag & RGN_FLAG_SEARCH_FILTER_ACTIVE);
UI: use popup draw style for redo panel
2018-09-11 11:22:08 +10:00
}
UI: support layout panels in popups Enables operators that uses `WM_operator_props_dialog_popup` or `redo` popup to use layout panels. Other popups would likely also support layout panels, only they need to set its dummy panel with `UI_popup_dummy_panel_set`. Popups don't normally use `Panel`, but that's the type that stores the layout panel states. Therefore, to use layout panels in a popup, one currently needs to create a dummy panel whose purpose is to store the layout panel states for as long as the popup is open. Alternatively, we could potentially also store the layout panel states somewhere else in the future for popups, but that might be a more involved change for now. See #119519 for an example script that uses layout panels in a popup. Pull Request: https://projects.blender.org/blender/blender/pulls/119519
2024-03-21 10:31:05 +01:00
/* Shared layout panel backdrop style between redo region and popups. */
if (block->panel && ELEM(region->regiontype, RGN_TYPE_HUD, RGN_TYPE_TEMPORARY)) {
/* TODO: Add as theme color. */
float subpanel_backcolor[4]{0.2f, 0.3f, 0.33f, 0.05f};
const bTheme *btheme = UI_GetTheme();
const float aspect = block->panel->runtime->block->aspect;
const float radius = btheme->tui.panel_roundness * U.widget_unit * 0.5f / aspect;
UI_draw_layout_panels_backdrop(region, block->panel, radius, subpanel_backcolor);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: BLF batch drawing naming - batching -> batch_draw. - ct & size -> len. - start/end -> begin/end (follow GL convention).
2018-03-31 13:09:03 +02:00
BLF_batch_draw_begin();
UI: Perf: Batch icons drawcalls together. For this we use a new shader that gets it's data from a uniform array. Vertex shader position the vertices using these data. Using glUniform is way faster than using imm for that matter. Like BLF rendering, UI icons are always (as far as I know) non occluded and displayed above everything else. They also does not overlap with texts so they can be batched at the same time.
2018-03-31 19:32:28 +02:00
UI_icon_draw_cache_begin();
UI: Perf: Use widget base batching Overall 10% more performance on general UI drawing time. This commit can introduce ordering problem on some elements. In this case you need to flush the widget cache to ensure the element that is going to be drawn is drawn on top of any widget base. To flush the cache use UI_widgetbase_draw_cache_flush. This is already done for BLF and Icons.
2018-04-06 14:30:20 +02:00
UI_widgetbase_draw_cache_begin();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 WIP commit for UI drawing. - Hooked up Diego's new Font API - Added Style definitions for fonts, currently it uses a different font for panel titles to show it. - Styles are in Userdef now too, still not finished - Userdef "DPI" will offer global control over font size, to match monitor size/resolution. It's meant to scale widgets and headers too btw, later. - Lots of code removed for old fonts, but that's unfinished. On todo: too much to mention, will continue happily tomorrow!
2009-04-09 18:11:18 +00:00
/* widgets */
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
UI: (Performance) Avoid drawing buttons out of view The UI was always drawing all buttons in a layout, no matter if they were scrolled out of view (as in, outside of the visible part of the region) or not. This means it's doing quite some work that can be avoided. UI drawing generally isn't a big bottleneck in Blender, so I don't expect huge speedups from this. But while playing back animation, we do redraw a fair bit of the UI, so in cases where there are many buttons out of view, it may bring a little FPS boost. E.g. say in complex node trees (the node editor is redrawn on animation playback in case there are animated values that need updated UI feedback). This also mitigates the issue in T92922 significantly. Differential Revision: https://developer.blender.org/T92922 Reviewed by: Brecht Van Lommel
2021-11-12 18:16:18 +01:00
if (but->flag & (UI_HIDDEN | UI_SCROLLED)) {
continue;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: (Performance) Avoid drawing buttons out of view The UI was always drawing all buttons in a layout, no matter if they were scrolled out of view (as in, outside of the visible part of the region) or not. This means it's doing quite some work that can be avoided. UI drawing generally isn't a big bottleneck in Blender, so I don't expect huge speedups from this. But while playing back animation, we do redraw a fair bit of the UI, so in cases where there are many buttons out of view, it may bring a little FPS boost. E.g. say in complex node trees (the node editor is redrawn on animation playback in case there are animated values that need updated UI feedback). This also mitigates the issue in T92922 significantly. Differential Revision: https://developer.blender.org/T92922 Reviewed by: Brecht Van Lommel
2021-11-12 18:16:18 +01:00
ui_but_to_pixelrect(&rect, region, block, but);
/* Optimization: Don't draw buttons that are not visible (outside view bounds). */
if (!ui_but_pixelrect_in_view(region, &rect)) {
continue;
}
/* XXX: figure out why invalid coordinates happen when closing render window */
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
/* and material preview is redrawn in main window (temp fix for bug #23848) */
UI: (Performance) Avoid drawing buttons out of view The UI was always drawing all buttons in a layout, no matter if they were scrolled out of view (as in, outside of the visible part of the region) or not. This means it's doing quite some work that can be avoided. UI drawing generally isn't a big bottleneck in Blender, so I don't expect huge speedups from this. But while playing back animation, we do redraw a fair bit of the UI, so in cases where there are many buttons out of view, it may bring a little FPS boost. E.g. say in complex node trees (the node editor is redrawn on animation playback in case there are animated values that need updated UI feedback). This also mitigates the issue in T92922 significantly. Differential Revision: https://developer.blender.org/T92922 Reviewed by: Brecht Van Lommel
2021-11-12 18:16:18 +01:00
if (rect.xmin < rect.xmax && rect.ymin < rect.ymax) {
ui_draw_but(C, region, &style, but, &rect);
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
}
2.5 WIP commit for UI drawing. - Hooked up Diego's new Font API - Added Style definitions for fonts, currently it uses a different font for panel titles to show it. - Styles are in Userdef now too, still not finished - Userdef "DPI" will offer global control over font size, to match monitor size/resolution. It's meant to scale widgets and headers too btw, later. - Lots of code removed for old fonts, but that's unfinished. On todo: too much to mention, will continue happily tomorrow!
2009-04-09 18:11:18 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Perf: Use widget base batching Overall 10% more performance on general UI drawing time. This commit can introduce ordering problem on some elements. In this case you need to flush the widget cache to ensure the element that is going to be drawn is drawn on top of any widget base. To flush the cache use UI_widgetbase_draw_cache_flush. This is already done for BLF and Icons.
2018-04-06 14:30:20 +02:00
UI_widgetbase_draw_cache_end();
UI: Perf: Batch icons drawcalls together. For this we use a new shader that gets it's data from a uniform array. Vertex shader position the vertices using these data. Using glUniform is way faster than using imm for that matter. Like BLF rendering, UI icons are always (as far as I know) non occluded and displayed above everything else. They also does not overlap with texts so they can be batched at the same time.
2018-03-31 19:32:28 +02:00
UI_icon_draw_cache_end();
Cleanup: BLF batch drawing naming - batching -> batch_draw. - ct & size -> len. - start/end -> begin/end (follow GL convention).
2018-03-31 13:09:03 +02:00
BLF_batch_draw_end();
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Draw hierarchy lines for tree-views Hierarchy lines (like we also have in the Outliner) make it easier to visually parse the hierarchy, and avoid confusion about nesting level. Especially when some items have icons and/or collapse chevrons and some not (thus different levels of visual indentation). They were planned for #93582 and #107881, also see https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#layer-groups. The drawing is implemented as a general tree-view feature, so all tree-views with collapsable items (which excludes the spreadsheet data-set tree view) will get them without further setup.
2023-07-06 17:00:44 +02:00
ui_block_views_draw_overlays(region, block);
Make UI block drawing closer to master There is no need to break assumptions of what's being modified by this call and what's restored. The changes in this function simply spread crappyness outside of the UI block.
2017-04-19 10:26:40 +02:00
/* restore matrix */
GPU_matrix: use Blender's naming conventions Thanks to @sergey for review
2018-07-15 15:27:15 +02:00
GPU_matrix_pop_projection();
GPU_matrix_pop();
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
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
static void ui_block_message_subscribe(ARegion *region, wmMsgBus *mbus, uiBlock *block)
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *but_prev = nullptr;
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
/* possibly we should keep the region this block is contained in? */
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBut *, but, &block->buttons) {
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
if (but->rnapoin.type && but->rnaprop) {
/* quick check to avoid adding buttons representing a vector, multiple times. */
Cleanup: unused args, indentation
2018-11-21 06:21:58 +11:00
if ((but_prev && (but_prev->rnaprop == but->rnaprop) &&
(but_prev->rnapoin.type == but->rnapoin.type) &&
(but_prev->rnapoin.data == but->rnapoin.data) &&
RNA: Cleanup PointerRNA struct The old layout of `PointerRNA` was confusing for historic reasons: ``` typedef struct PointerRNA { struct { void *data; } id; struct StructRNA *type; void *data; } PointerRNA; ``` This patch updates it to: ``` typedef struct PointerRNA { struct ID *owner_id; struct StructRNA *type; void *data; } PointerRNA; ``` Throughout the code base `id.data` was replaced with `owner_id`. Furthermore, many explicit pointer type casts were added which were implicit before. Some type casts to `ID *` were removed. Reviewers: brecht, campbellbarton Differential Revision: https://developer.blender.org/D5558
2019-08-23 09:52:12 +02:00
(but_prev->rnapoin.owner_id == but->rnapoin.owner_id)) == false)
{
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
/* TODO: could make this into utility function. */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmMsgSubscribeValue value = {};
value.owner = region;
value.user_data = region;
value.notify = ED_region_do_msg_notify_tag_redraw;
WM_msg_subscribe_rna(mbus, &but->rnapoin, but->rnaprop, &value, __func__);
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
but_prev = but;
}
}
}
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
void UI_region_message_subscribe(ARegion *region, wmMsgBus *mbus)
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11:00
{
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBlock *, block, &region->uiblocks) {
Cleanup: Rename ARegion variables from ar to region The old convention was easy to confuse with ScrArea. Part of https://developer.blender.org/T74432. This is mostly a batch rename with some manual fixing. Only single word variable names are changed, no prefixed/suffixed names. Brecht van Lommel and Campbell Barton both gave me a green light for this convention change. Also ran clan clang format on affected files.
2020-03-06 16:56:42 +01:00
ui_block_message_subscribe(region, mbus, block);
WM: message bus replacement for property notifiers Use dynamically generated message publish/subscribe so buttons and manipulators update properly. This resolves common glitches where manipulators weren't updating as well as the UI when add-ons exposed properties which hard coded listeners weren't checking for. Python can also publish/scribe changes via `bpy.msgbus`. See D2917
2017-11-13 19:43:34 +11: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
/* ************* EVENTS ************* */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int ui_but_is_pushed_ex(uiBut *but, double *value)
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
{
Code cleanup: use bool
2014-04-11 11:25:41 +10:00
int is_push = 0;
Spreadsheet: Dataset region for spreadsheet editor This patch adds a left aligned sidebar to the spreadsheet editor. This Sidebar can be used to navigate the geometry component types and attribute domains. It also provides a quick overview of domain sizes. It replaces the two dropdowns in the regions header. Next step will be to add the domain cycling shortcut using the CTRL + mouse wheel. Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin), Hans Goudey (HooglyBoogly). Differential Revision: https://developer.blender.org/D11046
2021-06-25 07:57:24 +02:00
if (but->pushed_state_func) {
Cleanup: Use C++ functor for button pushed query callback C-style callbacks often rely on `void` pointer arguments that are unsafe because of the removed type. C++ functors allow passing arbitrary data along the callback, plus convenient features like defining the callback using a lambda. Didn't port the `typedef` because it doesn't add much in this case, just hides the type from the reader who has to look it up first. Note that this function isn't used in the main branch currently.
2023-06-05 12:45:33 +02:00
return but->pushed_state_func(*but);
Spreadsheet: Dataset region for spreadsheet editor This patch adds a left aligned sidebar to the spreadsheet editor. This Sidebar can be used to navigate the geometry component types and attribute domains. It also provides a quick overview of domain sizes. It replaces the two dropdowns in the regions header. Next step will be to add the domain cycling shortcut using the CTRL + mouse wheel. Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin), Hans Goudey (HooglyBoogly). Differential Revision: https://developer.blender.org/D11046
2021-06-25 07:57:24 +02:00
}
Cleanup: clang-tidy
2021-06-29 10:37:00 +10:00
if (but->bit) {
Clenaup: odd use of ternary operators
2019-04-16 12:09:34 +02:00
const bool state = !ELEM(
but->type, UI_BTYPE_TOGGLE_N, UI_BTYPE_ICON_TOGGLE_N, UI_BTYPE_CHECKBOX_N);
while looking into a problem in interface.c, noticed ui_get_but_val() is called frequently when the return value isn't used (no functional change).
2011-03-18 05:42:16 +00:00
int lvalue;
code cleanup: defines with braces - end with '(void)0' so callers must end with ';' like normal function. ... without this some editors dont parse the source so well.
2012-05-27 12:21:13 +00:00
UI_GET_BUT_VALUE_INIT(but, *value);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
lvalue = int(*value);
code cleanup: split out defines in BKE_utildefines.h into BLO_blend_defs.h and ui defines in interface_intern.h
2012-09-03 10:12:25 +00:00
if (UI_BITBUT_TEST(lvalue, (but->bitnr))) {
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
is_push = state;
code cleanup: split out defines in BKE_utildefines.h into BLO_blend_defs.h and ui defines in interface_intern.h
2012-09-03 10:12:25 +00:00
}
else {
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
is_push = !state;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (but->type) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_BUT:
case UI_BTYPE_HOTKEY_EVENT:
case UI_BTYPE_KEY_EVENT:
case UI_BTYPE_COLOR:
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
case UI_BTYPE_DECORATOR:
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
is_push = -1;
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_BUT_TOGGLE:
case UI_BTYPE_TOGGLE:
case UI_BTYPE_ICON_TOGGLE:
case UI_BTYPE_CHECKBOX:
code cleanup: defines with braces - end with '(void)0' so callers must end with ';' like normal function. ... without this some editors dont parse the source so well.
2012-05-27 12:21:13 +00:00
UI_GET_BUT_VALUE_INIT(but, *value);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (*value != double(but->hardmin)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
is_push = true;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_ICON_TOGGLE_N:
case UI_BTYPE_TOGGLE_N:
case UI_BTYPE_CHECKBOX_N:
code cleanup: defines with braces - end with '(void)0' so callers must end with ';' like normal function. ... without this some editors dont parse the source so well.
2012-05-27 12:21:13 +00:00
UI_GET_BUT_VALUE_INIT(but, *value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (*value == 0.0) {
is_push = true;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_ROW:
case UI_BTYPE_LISTROW:
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
case UI_BTYPE_TAB:
UI: Support Displaying Enums as Tabs Adds `uiLayout.prop_tabs_enum(data, property, icon_only)` to BPY.
2018-10-29 21:20:58 +01:00
if ((but->type == UI_BTYPE_TAB) && but->rnaprop && but->custom_data) {
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
/* uiBut.custom_data points to data this tab represents (e.g. workspace).
* uiBut.rnapoin/prop store an active value (e.g. active workspace). */
if (RNA_property_type(but->rnaprop) == PROP_POINTER) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const PointerRNA active_ptr = RNA_property_pointer_get(&but->rnapoin, but->rnaprop);
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
if (active_ptr.data == but->custom_data) {
is_push = true;
}
}
UI: Support Displaying Enums as Tabs Adds `uiLayout.prop_tabs_enum(data, property, icon_only)` to BPY.
2018-10-29 21:20:58 +01:00
break;
}
else if (but->optype) {
break;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Support Displaying Enums as Tabs Adds `uiLayout.prop_tabs_enum(data, property, icon_only)` to BPY.
2018-10-29 21:20:58 +01:00
UI_GET_BUT_VALUE_INIT(but, *value);
/* support for rna enum buts */
if (but->rnaprop && (RNA_property_flag(but->rnaprop) & PROP_ENUM_FLAG)) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (int(*value) & int(but->hardmax)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
is_push = true;
}
UI: Support Displaying Enums as Tabs Adds `uiLayout.prop_tabs_enum(data, property, icon_only)` to BPY.
2018-10-29 21:20:58 +01:00
}
else {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (*value == double(but->hardmax)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
is_push = true;
}
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
}
break;
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
case UI_BTYPE_VIEW_ITEM: {
const uiButViewItem *view_item_but = (const uiButViewItem *)but;
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
is_push = -1;
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
if (view_item_but->view_item) {
Cleanup: Remove unnecessary C wrappers for UI view classes
2024-03-08 09:16:00 -05:00
is_push = view_item_but->view_item->is_active();
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
}
break;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
default:
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
is_push = -1;
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
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
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: add Visibility panel for objects The outliner should not be the only way for users to change these settings. The Python API was extended to keep these properties positive and keyframable. Differential Revision: https://developer.blender.org/D4889
2019-05-20 12:14:48 +02:00
if ((but->drawflag & UI_BUT_CHECKBOX_INVERT) && (is_push != -1)) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
is_push = !bool(is_push);
UI: add Visibility panel for objects The outliner should not be the only way for users to change these settings. The Python API was extended to keep these properties positive and keyframable. Differential Revision: https://developer.blender.org/D4889
2019-05-20 12:14:48 +02:00
}
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
return is_push;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int ui_but_is_pushed(uiBut *but)
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
{
double value = UI_BUT_VALUE_UNSET;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
return ui_but_is_pushed_ex(but, &value);
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_but_update_select_flag(uiBut *but, double *value)
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
switch (ui_but_is_pushed_ex(but, value)) {
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
case true:
but->flag |= UI_SELECT;
break;
case false:
but->flag &= ~UI_SELECT;
break;
style cleanup: if();
2012-10-07 09:48:59 +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
}
/* ************************************************ */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_lock_set(uiBlock *block, bool val, const char *lockstr)
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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (val) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
block->lock = val;
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->lockstr = lockstr;
2.5: ID datablock button back, previously known as std_libbuttons. The way this worked in 2.4x wasn't really clean, with events going all over the place and using dubious variables such as G.but->lockpoin or G.sima->menunr. It works as follows now, for example: xco= uiDefIDPoinButs(block, CTX_data_main(C), NULL, (ID**)&sima->image, ID_IM, &sima->pin, xco, yco, sima_idpoin_handle, UI_ID_BROWSE|UI_ID_RENAME|UI_ID_ADD_NEW|UI_ID_OPEN|UI_ID_DELETE|UI_ID_ALONE|UI_ID_PIN); The last two parameters are a callback function, and a list of events or functionalities that are supported. The callback function will then get the ID pointer + event to handle.
2009-02-06 16:40:14 +00:00
}
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_lock_clear(uiBlock *block)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
block->lock = false;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
block->lockstr = nullptr;
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
}
/* *********************** data get/set ***********************
* this either works with the pointed to data, or can work with
* an edit override pointer while dragging for example */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void ui_but_v3_get(uiBut *but, float vec[3])
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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->editvec) {
replace VECCOPY with copy_v3_v3, same for 2d copy, also added vec copy functions for int & char.
2011-11-07 01:38:32 +00:00
copy_v3_v3(vec, but->editvec);
RNA * The RNA viewer is now more integrated with the outliner, as a "Datablocks" view, with a tree structure. * Still some issues to be solved with persistence, and also memory usage is problematic when expanding a million vertices in a mesh for example, though it will not build closed parts of the tree.
2008-12-30 21:28:27 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
PropertyRNA *prop = but->rnaprop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
zero_v3(vec);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_property_type(prop) == PROP_FLOAT) {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
int tot = RNA_property_array_length(&but->rnapoin, prop);
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
BLI_assert(tot > 0);
if (tot == 3) {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
RNA_property_float_get_array(&but->rnapoin, prop, vec);
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
}
else {
tot = min_ii(tot, 3);
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
for (int a = 0; a < tot; a++) {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
vec[a] = RNA_property_float_get_index(&but->rnapoin, prop, a);
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
}
}
RNA * The RNA viewer is now more integrated with the outliner, as a "Datablocks" view, with a tree structure. * Still some issues to be solved with persistence, and also memory usage is problematic when expanding a million vertices in a mesh for example, though it will not build closed parts of the tree.
2008-12-30 21:28:27 +00:00
}
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_CHAR) {
Code cleanup: use 'const' for arrays (editors)
2014-04-27 00:22:49 +10:00
const char *cp = (char *)but->poin;
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
vec[0] = float(cp[0]) / 255.0f;
vec[1] = float(cp[1]) / 255.0f;
vec[2] = float(cp[2]) / 255.0f;
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
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_FLOAT) {
Code cleanup: use 'const' for arrays (editors)
2014-04-27 00:22:49 +10:00
const float *fp = (float *)but->poin;
replace VECCOPY with copy_v3_v3, same for 2d copy, also added vec copy functions for int & char.
2011-11-07 01:38:32 +00:00
copy_v3_v3(vec, fp);
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
}
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
else {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->editvec == nullptr) {
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
fprintf(stderr, "%s: can't get color, should never happen\n", __func__);
zero_v3(vec);
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (but->type == UI_BTYPE_UNITVEC) {
fix UI jump in normal buttons for buttons which didnt start out normalized.
2011-10-15 09:43:42 +00:00
normalize_v3(vec);
}
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void ui_but_v3_set(uiBut *but, const float vec[3])
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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->editvec) {
fix UI jump in normal buttons for buttons which didnt start out normalized.
2011-10-15 09:43:42 +00:00
copy_v3_v3(but->editvec, vec);
RNA * The RNA viewer is now more integrated with the outliner, as a "Datablocks" view, with a tree structure. * Still some issues to be solved with persistence, and also memory usage is problematic when expanding a million vertices in a mesh for example, though it will not build closed parts of the tree.
2008-12-30 21:28:27 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
PropertyRNA *prop = but->rnaprop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_property_type(prop) == PROP_FLOAT) {
make sure render layer names are unique when setting through rna.
2011-10-15 09:59:31 +00:00
int tot;
int a;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
tot = RNA_property_array_length(&but->rnapoin, prop);
minor cleanup to ui_get_but_vectorf / ui_set_but_vectorf, change the vector with one function call if its size 3.
2012-12-21 00:11:45 +00:00
BLI_assert(tot > 0);
if (tot == 3) {
RNA_property_float_set_array(&but->rnapoin, prop, vec);
}
else {
tot = min_ii(tot, 3);
for (a = 0; a < tot; a++) {
RNA_property_float_set_index(&but->rnapoin, prop, a, vec[a]);
}
make sure render layer names are unique when setting through rna.
2011-10-15 09:59:31 +00:00
}
RNA * The RNA viewer is now more integrated with the outliner, as a "Datablocks" view, with a tree structure. * Still some issues to be solved with persistence, and also memory usage is problematic when expanding a million vertices in a mesh for example, though it will not build closed parts of the tree.
2008-12-30 21:28:27 +00:00
}
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_CHAR) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *cp = (char *)but->poin;
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
cp[0] = char(lround(vec[0] * 255.0f));
cp[1] = char(lround(vec[1] * 255.0f));
cp[2] = char(lround(vec[2] * 255.0f));
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
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_FLOAT) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *fp = (float *)but->poin;
fix UI jump in normal buttons for buttons which didnt start out normalized.
2011-10-15 09:43:42 +00:00
copy_v3_v3(fp, vec);
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
}
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_is_float(const 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
{
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->pointype == UI_BUT_POIN_FLOAT && but->poin) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->rnaprop && RNA_property_type(but->rnaprop) == PROP_FLOAT) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
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
}
UI: add non-linear slider support This patch introduces non linear sliders. That means, that the movement of the mouse doesn't map linearly to the value of the slider. The following changes have been made. - Free logarithmic sliders with maximum range of (`0 <= x < inf`) - Logarithmic sliders with correct value indication bar. - Free cubic sliders with maximum range of (`-inf < x < inf`) - Cubic sliders with correct value indication bar. Cubic mapping has been added as well, because it's used for brush sizes in other applications (Krita for e.g.). To make a slider have a different scale type use following line in RNA: `RNA_def_property_ui_scale_type(prop, PROP_SCALE_LOGARITHMIC);` or: `RNA_def_property_ui_scale_type(prop, PROP_SCALE_CUBIC);` Test the precision, step size and soft-min if you change the scale type of a property as it will feel very different and may need tweaking. Ref D9074
2021-05-17 17:28:12 +10:00
PropertyScaleType ui_but_scale_type(const uiBut *but)
{
if (but->rnaprop) {
return RNA_property_ui_scale(but->rnaprop);
}
return PROP_SCALE_LINEAR;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_is_bool(const uiBut *but)
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
{
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (ELEM(but->type,
UI_BTYPE_TOGGLE,
UI_BTYPE_TOGGLE_N,
UI_BTYPE_ICON_TOGGLE,
UI_BTYPE_ICON_TOGGLE_N,
Asset shelf: Drag over checkboxes to enable/disable catalogs in selector Makes it possible to swipe over the checkboxes used to enable or disable catalogs in the asset catalog selector popup, to batch enable or disable the ones dragged over. Might also enable this feature for other cases where checkboxes are displayed.
2023-11-06 22:22:54 +01:00
UI_BTYPE_CHECKBOX,
UI_BTYPE_CHECKBOX_N,
UI: Support dragging over node panel headers to batch (un)collapse Makes it possible to swipe over panel header to batch open/collapse all panels the mouse draged over. Normal panels and sub-panels support this too. Two changes were needed: - Support "drag toggle" feature for `UI_BTYPE_BUT_TOGGLE` - all toggle buttons should/can support this. - Allow querying the pushed state from the button used for the collapsing. Multiple ways to do this, in this case simply using the pushed state query callback seemed simplest. Pull Request: https://projects.blender.org/blender/blender/pulls/114560
2023-11-07 10:59:33 +01:00
UI_BTYPE_BUT_TOGGLE,
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
UI_BTYPE_TAB))
{
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->rnaprop && RNA_property_type(but->rnaprop) == PROP_BOOLEAN) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if ((but->rnaprop && RNA_property_type(but->rnaprop) == PROP_ENUM) &&
Clang Format: bump to version 17 Along with the 4.1 libraries upgrade, we are bumping the clang-format version from 8-12 to 17. This affects quite a few files. If not already the case, you may consider pointing your IDE to the clang-format binary bundled with the Blender precompiled libraries.
2024-01-02 18:12:54 +01:00
(but->type == UI_BTYPE_ROW))
{
UI: add Shift-Drag to multiselect expanded enum items too. Differential Revision: https://developer.blender.org/D928
2014-12-10 17:00:54 +01:00
return true;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: add Shift-Drag to multiselect expanded enum items too. Differential Revision: https://developer.blender.org/D928
2014-12-10 17:00:54 +01:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
Toggle-Drag UI Feature Dragging on toggle buttons can now be used to press multiple buttons at once, especially useful for layer and outliner buttons. notes: - automatically enabled for all toggle buttons (may change this if it becomes a problem). - only buttons of the same type are pressed (helps avoid annoyances eg; dragging past layer buttons onto other 3d header buttons and pressing by accident). - automatic axis locking - dragging will lock to X/Y depending on the initial drag direction, makes swipe motions work better, especially with the outliner. implementation details: - may re-implement as a region handler (currently its a modal operator). - checking buttons in-between cursor motion events could be more efficient (but currently works ok). - button execution needs to be improved (currently executing a button thats not under the mouse needed a workaround for passing uiHandleButtonData), requires further changes to UI code, will do next.
2013-02-22 05:56:20 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_is_unit(const uiBut *but)
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
{
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
const UnitSettings *unit = but->block->unit;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
const int unit_type = UI_but_unit_type_get(but);
- bone roll now in degrees not radians. - rna buttons with units set now use the units base value for snapping. - bone head/tail radius could be set negative. matt: removed a check in ui_is_but_unit() which made angle buttons return false, what was this for?
2010-09-16 04:19:22 +00:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (unit_type == PROP_UNIT_NONE) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
- bone roll now in degrees not radians. - rna buttons with units set now use the units base value for snapping. - bone head/tail radius could be set negative. matt: removed a check in ui_is_but_unit() which made angle buttons return false, what was this for?
2010-09-16 04:19:22 +00:00
style cleanup
2012-08-19 10:41:27 +00:00
#if 1 /* removed so angle buttons get correct snapping */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (ui_but_is_unit_radians_ex(unit, unit_type)) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
- bone roll now in degrees not radians. - rna buttons with units set now use the units base value for snapping. - bone head/tail radius could be set negative. matt: removed a check in ui_is_but_unit() which made angle buttons return false, what was this for?
2010-09-16 04:19:22 +00:00
#endif
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
/* for now disable time unit conversion */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (unit_type == PROP_UNIT_TIME) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
bugfix [#21136] End frame And Cur Frame setting is broken with Metric/Imperial units [26876] and minor changes for unit.c, no functional change.
2010-02-15 21:07:14 +00:00
store a pointer to the units system in the uiBlock since the button code was doing context lookups for the scene quite a lot.
2011-08-18 20:01:30 +00:00
if (unit->system == USER_UNIT_NONE) {
Fix Cycles time limit not showing unit when scene units are set to none
2023-10-23 12:09:34 +02:00
/* These types have units irrespective of scene units. */
if (!ELEM(unit_type, PROP_UNIT_ROTATION, PROP_UNIT_TIME_ABSOLUTE)) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
fix for error in recent commit, wasn't masking out the non unit subtype flags.
2010-12-10 13:15:11 +00:00
}
Radians -> Degrees (in UI) Rotations are now stored internally as radians, while exposing degrees in the UI - in the graph editor and UI controls. This is done in two areas: 1) Using the unit system to convert RNA data to display as degrees in the UI controls 2) FCurves now use degrees for rotation, so you can edit in the graph editor what you see in the UI. All rotation data is consistently accessible in DNA and RNA as radians, degrees are only used for the UI controls and graph editor. This commit includes conversions will convert old files (stored data and also fcurve data) to the new units, hopefully everything should go smoothly! Part of this also changes a few properties that were hard-coded as degrees before (such as IK pole angle and brush texture rotation) to also use the same consistent system of radians (dna/rna) and degrees (ui). Thanks to Joshua for hints and review here too.
2010-01-25 06:24:05 +00:00
}
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_is_compatible(const uiBut *but_a, const uiBut *but_b)
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
{
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but_a->type != but_b->type) {
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
if (but_a->pointype != but_b->pointype) {
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
if (but_a->rnaprop) {
RNA: Cleanup PointerRNA struct The old layout of `PointerRNA` was confusing for historic reasons: ``` typedef struct PointerRNA { struct { void *data; } id; struct StructRNA *type; void *data; } PointerRNA; ``` This patch updates it to: ``` typedef struct PointerRNA { struct ID *owner_id; struct StructRNA *type; void *data; } PointerRNA; ``` Throughout the code base `id.data` was replaced with `owner_id`. Furthermore, many explicit pointer type casts were added which were implicit before. Some type casts to `ID *` were removed. Reviewers: brecht, campbellbarton Differential Revision: https://developer.blender.org/D5558
2019-08-23 09:52:12 +02:00
/* skip 'rnapoin.data', 'rnapoin.owner_id'
UI: let multi-num-drag change different ID values Handy for property-chart addon.
2014-10-29 22:35:09 +01:00
* allow different data to have the same props edited at once */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but_a->rnapoin.type != but_b->rnapoin.type) {
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
if (RNA_property_type(but_a->rnaprop) != RNA_property_type(but_b->rnaprop)) {
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
if (RNA_property_subtype(but_a->rnaprop) != RNA_property_subtype(but_b->rnaprop)) {
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return false;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: multi-drag number button editing clicking and dragging down edits multiple number buttons at once. (patch D270)
2014-02-08 09:34:01 +11:00
return true;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_is_rna_valid(uiBut *but)
RNA & interface functions for checking if RNA in a button uses valid rna property (not currently used).
2011-03-24 09:27:41 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->rnaprop == nullptr || RNA_struct_contains_property(&but->rnapoin, but->rnaprop)) {
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
RNA & interface functions for checking if RNA in a button uses valid rna property (not currently used).
2011-03-24 09:27:41 +00:00
}
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
printf("property removed %s: %p\n", but->drawstr.c_str(), but->rnaprop);
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return false;
RNA & interface functions for checking if RNA in a button uses valid rna property (not currently used).
2011-03-24 09:27:41 +00:00
}
Fix T45944: Ctrl+Wheel to cycle values failes in toolshelf Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes) This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
2015-09-05 19:28:24 +02:00
bool ui_but_supports_cycling(const uiBut *but)
{
Cleanup: remove redundant parentheses
2021-07-16 11:45:52 +10:00
return (ELEM(but->type, UI_BTYPE_ROW, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER, UI_BTYPE_LISTBOX) ||
Fix T45944: Ctrl+Wheel to cycle values failes in toolshelf Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes) This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
2015-09-05 19:28:24 +02:00
(but->type == UI_BTYPE_MENU && ui_but_menu_step_poll(but)) ||
UI Code Quality: Use derived struct for color buttons For the main rationale behind this design, see 03b122e2a18df. Further, this removes users of `uiBut.a1`/`uiBut.a2`, which is a very ugly design choice (hard to reason about). Part of Part of T74432.
2020-08-07 15:02:07 +02:00
(but->type == UI_BTYPE_COLOR && ((uiButColor *)but)->is_pallete_color) ||
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
(but->menu_step_func != nullptr));
Fix T45944: Ctrl+Wheel to cycle values failes in toolshelf Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes) This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
2015-09-05 19:28:24 +02:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
double ui_but_value_get(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
{
double value = 0.0;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->editval) {
return *(but->editval);
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->poin == nullptr && but->rnapoin.data == nullptr) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
return 0.0;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
PropertyRNA *prop = but->rnaprop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Revert "Cleanup: consistently use rnaindex -1 to mean the no or entire array" This reverts commit 8ed65fe6de9a386f99b0ed7b255f76beaa86ae5b. Fix #108553: Alt + value change doesn't work for various inputs Fix #108621: Driven values are no longer marked in purple
2023-06-06 11:30:49 +02:00
BLI_assert(but->rnaindex != -1);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (RNA_property_type(prop)) {
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
case PROP_BOOLEAN:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
Cleanup: use explicit casts when assigning booleans to floats While valid, this isn't so common and cppcheck warns about this, use explicit casts to suppress the warning, also correct "true" being assigned to a float value.
2024-04-01 22:16:23 +11:00
value = double(RNA_property_boolean_get_index(&but->rnapoin, prop, but->rnaindex));
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
Cleanup: use explicit casts when assigning booleans to floats While valid, this isn't so common and cppcheck warns about this, use explicit casts to suppress the warning, also correct "true" being assigned to a float value.
2024-04-01 22:16:23 +11:00
value = double(RNA_property_boolean_get(&but->rnapoin, prop));
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
break;
case PROP_INT:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
value = RNA_property_int_get_index(&but->rnapoin, prop, but->rnaindex);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
value = RNA_property_int_get(&but->rnapoin, prop);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
break;
case PROP_FLOAT:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
value = RNA_property_float_get_index(&but->rnapoin, prop, but->rnaindex);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
value = RNA_property_float_get(&but->rnapoin, prop);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
break;
case PROP_ENUM:
Remove evaluated RNA pointer lookup in interface Since there is a flush of evaluated values back to the original for an active dependency graph we don't need this lookup anymore. Not only it slows interface drawing down, but also is becoming in a way of the upcoming fix.
2019-04-01 10:18:07 +02:00
value = RNA_property_enum_get(&but->rnapoin, prop);
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
break;
default:
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = 0.0;
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
break;
}
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_CHAR) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *(char *)but->poin;
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
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_SHORT) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *(short *)but->poin;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_INT) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *(int *)but->poin;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_FLOAT) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *(float *)but->poin;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
return value;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void ui_but_value_set(uiBut *but, double value)
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
{
Cleanup: spelling in comments
2021-10-06 14:44:27 +11:00
/* Value is a HSV value: convert to RGB. */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
PropertyRNA *prop = but->rnaprop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_property_editable(&but->rnapoin, prop)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (RNA_property_type(prop)) {
RNA * Wrap most user editable data in DNA_mesh_types.h and DNA_meshdata_types.h. Still needs to be improved in some areas though, especially how to deal with data layers (expose per element or as array, or both?), and data in face corners (bmesh type data structures are more logical here). Tweaks to RNA defining to make some cases easier: * Added range callback function for int/float. * Added 'skip' callback for listbase and array iterators to skip items in the collection. * Extra error print when calling wrong define_property_*_sdna functions. * Also made button code respect non_editable flag, is quick change though, need to add support for properly graying out etc.
2008-11-24 12:12:24 +00:00
case PROP_BOOLEAN:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
RNA: C API * RNA_blender.h is now generated along with the other files. It is not used anywhere yet, and still located quite hidden next to the other rna_*_gen.c files. Read only access for now. * Inherited properties are not copied from the base anymore but iterated over. Patch by Vekoon, thanks! * Array get/set callbacks now do the whole array instead of getting an index. This is needed for some layers for example so python can set the array as a whole, otherwise the check that one layer has to be enabled at all times gets in the way. Also nicer for the C API. * Also some changes to returning pointers to make the API cleaner, got rid of the type() callback and instead let get() return PointerRNA with the type included. The C API looks like this currently: http://users.pandora.be/blendix/RNA_blender.h
2009-02-02 19:57:57 +00:00
RNA_property_boolean_set_index(&but->rnapoin, prop, but->rnaindex, value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
RNA * Disable editable pointers for now, difficult to support well. * Swap parameters in RNA_access.h functions to make it more consistent. * Rename rna members for operators to wmOperatorType.srna, and wmOperator.ptr, to make the distincton a bit clearer. • Removed the RNA_int_default and similar functions, they're too confusing. RNA_property_is_set can still be used to achieve the same goal. * Add functions to create RNA pointers. Some example code for RNA data access and operator properties: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNAExampleCode
2008-11-24 15:51:55 +00:00
RNA_property_boolean_set(&but->rnapoin, prop, value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
RNA * Wrap most user editable data in DNA_mesh_types.h and DNA_meshdata_types.h. Still needs to be improved in some areas though, especially how to deal with data layers (expose per element or as array, or both?), and data in face corners (bmesh type data structures are more logical here). Tweaks to RNA defining to make some cases easier: * Added range callback function for int/float. * Added 'skip' callback for listbase and array iterators to skip items in the collection. * Extra error print when calling wrong define_property_*_sdna functions. * Also made button code respect non_editable flag, is quick change though, need to add support for properly graying out etc.
2008-11-24 12:12:24 +00:00
break;
case PROP_INT:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
RNA_property_int_set_index(&but->rnapoin, prop, but->rnaindex, int(value));
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
RNA_property_int_set(&but->rnapoin, prop, int(value));
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
RNA * Wrap most user editable data in DNA_mesh_types.h and DNA_meshdata_types.h. Still needs to be improved in some areas though, especially how to deal with data layers (expose per element or as array, or both?), and data in face corners (bmesh type data structures are more logical here). Tweaks to RNA defining to make some cases easier: * Added range callback function for int/float. * Added 'skip' callback for listbase and array iterators to skip items in the collection. * Extra error print when calling wrong define_property_*_sdna functions. * Also made button code respect non_editable flag, is quick change though, need to add support for properly graying out etc.
2008-11-24 12:12:24 +00:00
break;
case PROP_FLOAT:
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (RNA_property_array_check(prop)) {
RNA: C API * RNA_blender.h is now generated along with the other files. It is not used anywhere yet, and still located quite hidden next to the other rna_*_gen.c files. Read only access for now. * Inherited properties are not copied from the base anymore but iterated over. Patch by Vekoon, thanks! * Array get/set callbacks now do the whole array instead of getting an index. This is needed for some layers for example so python can set the array as a whole, otherwise the check that one layer has to be enabled at all times gets in the way. Also nicer for the C API. * Also some changes to returning pointers to make the API cleaner, got rid of the type() callback and instead let get() return PointerRNA with the type included. The C API looks like this currently: http://users.pandora.be/blendix/RNA_blender.h
2009-02-02 19:57:57 +00:00
RNA_property_float_set_index(&but->rnapoin, prop, but->rnaindex, value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
RNA * Disable editable pointers for now, difficult to support well. * Swap parameters in RNA_access.h functions to make it more consistent. * Rename rna members for operators to wmOperatorType.srna, and wmOperator.ptr, to make the distincton a bit clearer. • Removed the RNA_int_default and similar functions, they're too confusing. RNA_property_is_set can still be used to achieve the same goal. * Add functions to create RNA pointers. Some example code for RNA data access and operator properties: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNAExampleCode
2008-11-24 15:51:55 +00:00
RNA_property_float_set(&but->rnapoin, prop, value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
RNA * Wrap most user editable data in DNA_mesh_types.h and DNA_meshdata_types.h. Still needs to be improved in some areas though, especially how to deal with data layers (expose per element or as array, or both?), and data in face corners (bmesh type data structures are more logical here). Tweaks to RNA defining to make some cases easier: * Added range callback function for int/float. * Added 'skip' callback for listbase and array iterators to skip items in the collection. * Extra error print when calling wrong define_property_*_sdna functions. * Also made button code respect non_editable flag, is quick change though, need to add support for properly graying out etc.
2008-11-24 12:12:24 +00:00
break;
case PROP_ENUM:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_property_flag(prop) & PROP_ENUM_FLAG) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
int ivalue = int(value);
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* toggle for enum/flag buttons */
ivalue ^= RNA_property_enum_get(&but->rnapoin, prop);
support for PROP_ENUM_FLAG buttons, these were only supported by python.
2010-09-23 07:31:44 +00:00
RNA_property_enum_set(&but->rnapoin, prop, ivalue);
}
else {
RNA_property_enum_set(&but->rnapoin, prop, value);
}
RNA * Wrap most user editable data in DNA_mesh_types.h and DNA_meshdata_types.h. Still needs to be improved in some areas though, especially how to deal with data layers (expose per element or as array, or both?), and data in face corners (bmesh type data structures are more logical here). Tweaks to RNA defining to make some cases easier: * Added range callback function for int/float. * Added 'skip' callback for listbase and array iterators to skip items in the collection. * Extra error print when calling wrong define_property_*_sdna functions. * Also made button code respect non_editable flag, is quick change though, need to add support for properly graying out etc.
2008-11-24 12:12:24 +00:00
break;
default:
break;
}
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
minor speedup for UI draw code, noticed ui_get_but_val() could be called 3-5 times per button draw, for RNA buttons this gets the entire array for each call so its not great to call many times.
2011-06-16 06:00:02 +00:00
/* we can't be sure what RNA set functions actually do,
* so leave this unset */
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = UI_BUT_VALUE_UNSET;
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
}
style cleanup
2012-10-14 13:08:19 +00:00
else if (but->pointype == 0) {
/* pass */
}
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
else {
/* first do rounding */
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
if (but->pointype == UI_BUT_POIN_CHAR) {
Cleanup: use clamped rounding functions
2017-09-18 21:11:41 +10:00
value = round_db_to_uchar_clamp(value);
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
}
else if (but->pointype == UI_BUT_POIN_SHORT) {
Cleanup: use clamped rounding functions
2017-09-18 21:11:41 +10:00
value = round_db_to_short_clamp(value);
}
else if (but->pointype == UI_BUT_POIN_INT) {
value = round_db_to_int_clamp(value);
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
}
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
else if (but->pointype == UI_BUT_POIN_FLOAT) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
float fval = float(value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (fval >= -0.00001f && fval <= 0.00001f) {
/* prevent negative zero */
fval = 0.0f;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = fval;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* then set value with possible edit override */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->editval) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *but->editval = value;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (but->pointype == UI_BUT_POIN_CHAR) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value = *((char *)but->poin) = char(value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (but->pointype == UI_BUT_POIN_SHORT) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value = *((short *)but->poin) = short(value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (but->pointype == UI_BUT_POIN_INT) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value = *((int *)but->poin) = int(value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else if (but->pointype == UI_BUT_POIN_FLOAT) {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value = *((float *)but->poin) = float(value);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_select_flag(but, &value);
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
}
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
int ui_but_string_get_maxncpy(uiBut *but)
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
{
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU)) {
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
return but->hardmax;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return UI_MAX_DRAW_STR;
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *ui_but_drag_multi_edit_get(uiBut *but)
Fix T38809: regression, text cursor offset in number buttons Use the same offset for all edit-buttons now.
2014-02-25 10:28:41 +11:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *return_but = nullptr;
Fix T38809: regression, text cursor offset in number buttons Use the same offset for all edit-buttons now.
2014-02-25 10:28:41 +11:00
BLI_assert(but->flag & UI_BUT_DRAG_MULTI);
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBut *, but_iter, &but->block->buttons) {
Fix T38809: regression, text cursor offset in number buttons Use the same offset for all edit-buttons now.
2014-02-25 10:28:41 +11:00
if (but_iter->editstr) {
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
return_but = but_iter;
Fix T38809: regression, text cursor offset in number buttons Use the same offset for all edit-buttons now.
2014-02-25 10:28:41 +11:00
break;
}
}
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
return return_but;
Fix T38809: regression, text cursor offset in number buttons Use the same offset for all edit-buttons now.
2014-02-25 10:28:41 +11:00
}
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
static double ui_get_but_scale_unit(uiBut *but, double value)
{
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
const UnitSettings *unit = but->block->unit;
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int unit_type = UI_but_unit_type_get(but);
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
Move bUnit_getScaleUnit -> BKE_scene_unit_scale unit.c intentionally doesn't include DNA or BKE headers (except its own)
2014-08-26 20:52:07 +10:00
/* Time unit is a bit special, not handled by BKE_scene_unit_scale() for now. */
Cleanup: spelling in comments
2021-07-30 16:16:38 +10:00
if (unit_type == PROP_UNIT_TIME) { /* WARNING: using evil_C :| */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
Scene *scene = CTX_data_scene(static_cast<const bContext *>(but->block->evil_C));
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
return FRA2TIME(value);
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return BKE_scene_unit_scale(unit, RNA_SUBTYPE_UNIT_VALUE(unit_type), value);
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
}
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
void ui_but_convert_to_unit_alt_name(uiBut *but, char *str, size_t str_maxncpy)
patch [#23758] Better handling of UTF chars in UNITS fields (lengths, angles, etc.) from Lorenzo Tozzi (oni_niubbo) with minor edits. --- from the tracker The present situation is this: due to bug#22274, during editing, UTF chars are stripped from buttons with a unit associated (length, angles, etc.). Example: if the button displays '90°' and you click on it with LMB, the editing string will become '90'. The problem arises if you use microns: '34µm' becomes '34' that blender interprets as 34 meters. So clicking on a button and hitting enter won't confirm the previous value, but will change it (very badly also). Of course nobody is using microns in blender, but the problem will arise when we will implement areas and option 'Separate Units' will be enabled. The value '2m² 3cm²' will become '2m' during editing. This patch solves the problem rewriting the string in a smarter way than just stripping the UTF chars: the unit is translated from unit->name_short ('µm') to unit->name_alt ('um'). So clicking on '34µm' the editing string will become '34um'. --- end note: rather then allowing empty strings in name_alt field I made it so if the unit system was the default one a NULL name_alt will just strip the string, since its the default its not needed.
2010-09-15 17:37:00 +00:00
{
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (!ui_but_is_unit(but)) {
return;
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
const UnitSettings *unit = but->block->unit;
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
const int unit_type = UI_but_unit_type_get(but);
char *orig_str;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
orig_str = BLI_strdup(str);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BKE_unit_name_to_alt(
str, str_maxncpy, orig_str, unit->system, RNA_SUBTYPE_UNIT_VALUE(unit_type));
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
MEM_freeN(orig_str);
patch [#23758] Better handling of UTF chars in UNITS fields (lengths, angles, etc.) from Lorenzo Tozzi (oni_niubbo) with minor edits. --- from the tracker The present situation is this: due to bug#22274, during editing, UTF chars are stripped from buttons with a unit associated (length, angles, etc.). Example: if the button displays '90°' and you click on it with LMB, the editing string will become '90'. The problem arises if you use microns: '34µm' becomes '34' that blender interprets as 34 meters. So clicking on a button and hitting enter won't confirm the previous value, but will change it (very badly also). Of course nobody is using microns in blender, but the problem will arise when we will implement areas and option 'Separate Units' will be enabled. The value '2m² 3cm²' will become '2m' during editing. This patch solves the problem rewriting the string in a smarter way than just stripping the UTF chars: the unit is translated from unit->name_short ('µm') to unit->name_alt ('um'). So clicking on '34µm' the editing string will become '34um'. --- end note: rather then allowing empty strings in name_alt field I made it so if the unit system was the default one a NULL name_alt will just strip the string, since its the default its not needed.
2010-09-15 17:37:00 +00:00
}
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
/**
Cleanup: use colon separator after parameter Helps separate variable names from descriptive text. Was already used in some parts of the code, double space and dashes were used elsewhere.
2018-12-12 12:50:58 +11:00
* \param float_precision: Override the button precision.
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
*/
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
static void ui_get_but_string_unit(
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
uiBut *but, char *str, int str_maxncpy, double value, bool pad, int float_precision)
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
{
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
const UnitSettings *unit = but->block->unit;
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int unit_type = UI_but_unit_type_get(but);
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
int precision;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: remove unit scale initialization in UI logic Versioning logic was added since 2.5x
2024-03-29 16:28:15 +11:00
BLI_assert(unit->scale_length > 0.0f);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
/* Use precision override? */
if (float_precision == -1) {
/* Sanity checks */
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
precision = int(ui_but_get_float_precision(but));
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (precision > UI_PRECISION_FLOAT_MAX) {
precision = UI_PRECISION_FLOAT_MAX;
}
else if (precision == -1) {
precision = 2;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
else {
precision = float_precision;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Rename public "bUnit" functions This commit renames the functions in "BKE_unit.h` to be consistent with the naming in the rest of blenkernel. bUnit_AsString -> BKE_unit_value_as_string_adaptive bUnit_AsString2 -> BKE_unit_value_as_string bUnit_ReplaceString -> BKE_unit_replace_string bUnit_ApplyPreferredUnit -> BKE_unit_apply_preferred_unit bUnit_ToUnitAltName -> BKE_unit_name_to_alt bUnit_ClosestScalar -> BKE_unit_closest_scalar bUnit_BaseScalar -> BKE_unit_base_scalar bUnit_IsValid -> BKE_unit_is_valid bUnit_GetSystem -> BKE_unit_system_get bUnit_GetBaseUnit -> BKE_unit_base_get bUnit_GetBaseUnitOfType -> BKE_unit_base_of_type_get bUnit_GetName -> BKE_unit_name_get bUnit_GetNameDisplay -> BKE_unit_display_name_get bUnit_GetIdentifier -> BKE_unit_identifier_get bUnit_GetScaler -> BKE_unit_scalar_get bUnit_IsSuppressed -> BKE_unit_is_suppressed Differential Revision: https://developer.blender.org/D8828
2020-09-09 08:41:15 -05:00
BKE_unit_value_as_string(str,
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
str_maxncpy,
Cleanup: Rename public "bUnit" functions This commit renames the functions in "BKE_unit.h` to be consistent with the naming in the rest of blenkernel. bUnit_AsString -> BKE_unit_value_as_string_adaptive bUnit_AsString2 -> BKE_unit_value_as_string bUnit_ReplaceString -> BKE_unit_replace_string bUnit_ApplyPreferredUnit -> BKE_unit_apply_preferred_unit bUnit_ToUnitAltName -> BKE_unit_name_to_alt bUnit_ClosestScalar -> BKE_unit_closest_scalar bUnit_BaseScalar -> BKE_unit_base_scalar bUnit_IsValid -> BKE_unit_is_valid bUnit_GetSystem -> BKE_unit_system_get bUnit_GetBaseUnit -> BKE_unit_base_get bUnit_GetBaseUnitOfType -> BKE_unit_base_of_type_get bUnit_GetName -> BKE_unit_name_get bUnit_GetNameDisplay -> BKE_unit_display_name_get bUnit_GetIdentifier -> BKE_unit_identifier_get bUnit_GetScaler -> BKE_unit_scalar_get bUnit_IsSuppressed -> BKE_unit_is_suppressed Differential Revision: https://developer.blender.org/D8828
2020-09-09 08:41:15 -05:00
ui_get_but_scale_unit(but, value),
precision,
RNA_SUBTYPE_UNIT_VALUE(unit_type),
unit,
pad);
added time units, currently only used when metric or imperial are enabled. long/short units... day,d, hour,hr,h, minute,min,m, second,sec,s, millisecond,ms, microsecond,us Also may fix some bugs that were reported. Note, to convert fps to time evil_C needs to be used to get the scene.
2009-08-12 05:20:16 +00:00
}
[#22873] Snap to increment isn't working that expected when Units set to Metric or Imperial - minor - pick the closest unit that matches the existing step size. - set the distance subtype on some camera flags. - commented mesh flag 'ME_ISDONE' its nolonger used.
2010-07-24 00:24:58 +00:00
static float ui_get_but_step_unit(uiBut *but, float step_default)
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int unit_type = RNA_SUBTYPE_UNIT_VALUE(UI_but_unit_type_get(but));
Fix T46134: units degrees increment are too small The user interface was ignoring the precision step size for degrees, making all rotation inputs drag by a 100th of a degree. Now use a 10th of a degree instead.
2015-09-17 21:50:40 +10:00
const double step_orig = step_default * UI_PRECISION_FLOAT_SCALE;
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* Scaling up 'step_origg ' here is a bit arbitrary,
* its just giving better scales from user POV */
Fix T46134: units degrees increment are too small The user interface was ignoring the precision step size for degrees, making all rotation inputs drag by a 100th of a degree. Now use a 10th of a degree instead.
2015-09-17 21:50:40 +10:00
const double scale_step = ui_get_but_scale_unit(but, step_orig * 10);
Cleanup: Rename public "bUnit" functions This commit renames the functions in "BKE_unit.h` to be consistent with the naming in the rest of blenkernel. bUnit_AsString -> BKE_unit_value_as_string_adaptive bUnit_AsString2 -> BKE_unit_value_as_string bUnit_ReplaceString -> BKE_unit_replace_string bUnit_ApplyPreferredUnit -> BKE_unit_apply_preferred_unit bUnit_ToUnitAltName -> BKE_unit_name_to_alt bUnit_ClosestScalar -> BKE_unit_closest_scalar bUnit_BaseScalar -> BKE_unit_base_scalar bUnit_IsValid -> BKE_unit_is_valid bUnit_GetSystem -> BKE_unit_system_get bUnit_GetBaseUnit -> BKE_unit_base_get bUnit_GetBaseUnitOfType -> BKE_unit_base_of_type_get bUnit_GetName -> BKE_unit_name_get bUnit_GetNameDisplay -> BKE_unit_display_name_get bUnit_GetIdentifier -> BKE_unit_identifier_get bUnit_GetScaler -> BKE_unit_scalar_get bUnit_IsSuppressed -> BKE_unit_is_suppressed Differential Revision: https://developer.blender.org/D8828
2020-09-09 08:41:15 -05:00
const double step = BKE_unit_closest_scalar(scale_step, but->block->unit->system, unit_type);
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
add checks for bad args to RNA_def_property_ui_range & RNA_def_property_range and fix one instance where (min > max). also remove redundant float/double conversion in ui_get_but_step_unit()
2013-09-02 22:28:18 +00:00
/* -1 is an error value */
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (step == -1.0f) {
return step_default;
}
const double scale_unit = ui_get_but_scale_unit(but, 1.0);
const double step_unit = BKE_unit_closest_scalar(
scale_unit, but->block->unit->system, unit_type);
double step_final;
Fix T46134: units degrees increment are too small The user interface was ignoring the precision step size for degrees, making all rotation inputs drag by a 100th of a degree. Now use a 10th of a degree instead.
2015-09-17 21:50:40 +10:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
BLI_assert(step > 0.0);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
step_final = (step / scale_unit) / double(UI_PRECISION_FLOAT_SCALE);
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (step == step_unit) {
/* Logic here is to scale by the original 'step_orig'
* only when the unit step matches the scaled step.
*
* This is needed for units that don't have a wide range of scales (degrees for eg.).
* Without this we can't select between a single degree, or a 10th of a degree.
*/
step_final *= step_orig;
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
}
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
return float(step_final);
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
}
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
void ui_but_string_get_ex(uiBut *but,
char *str,
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
const size_t str_maxncpy,
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
const int float_precision,
const bool use_exp_float,
bool *r_use_exp_float)
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
{
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
if (r_use_exp_float) {
*r_use_exp_float = false;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
if (but->rnaprop && ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU, UI_BTYPE_TAB)) {
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const PropertyType type = RNA_property_type(but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int buf_len;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
const char *buf = nullptr;
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
if ((but->type == UI_BTYPE_TAB) && (but->custom_data)) {
StructRNA *ptr_type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
/* uiBut.custom_data points to data this tab represents (e.g. workspace).
* uiBut.rnapoin/prop store an active value (e.g. active workspace). */
RNA: return PointerRNA from rna create functions There are a couple of functions that create rna pointers. For example `RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those take an output parameter `r_ptr` as last argument. This patch changes it so that the functions actually return a` PointerRNA` instead of using the output parameters. This has a few benefits: * Output parameters should only be used when there is an actual benefit. Otherwise, one should default to returning the value. * It's simpler to use the API in the large majority of cases (note that this patch reduces the number of lines of code). * It allows the `PointerRNA` to be const on the call-site, if that is desired. No performance regression has been measured in production files. If one of these functions happened to be called in a hot loop where there is a regression, the solution should be to use an inline function there which allows the compiler to optimize it even better. Pull Request: https://projects.blender.org/blender/blender/pulls/111976
2023-09-06 00:48:50 +02:00
PointerRNA ptr = RNA_pointer_create(but->rnapoin.owner_id, ptr_type, but->custom_data);
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
buf = RNA_struct_name_get_alloc(&ptr, str, str_maxncpy, &buf_len);
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
}
else if (type == PROP_STRING) {
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
/* RNA string */
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
buf = RNA_property_string_get_alloc(&but->rnapoin, but->rnaprop, str, str_maxncpy, &buf_len);
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
else if (type == PROP_ENUM) {
/* RNA enum */
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int value = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (RNA_property_enum_name(static_cast<bContext *>(but->block->evil_C),
&but->rnapoin,
but->rnaprop,
value,
&buf))
{
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_strncpy(str, buf, str_maxncpy);
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
buf = str;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (type == PROP_POINTER) {
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
/* RNA pointer */
style cleanup: interface
2012-03-30 01:51:25 +00:00
PointerRNA ptr = RNA_property_pointer_get(&but->rnapoin, but->rnaprop);
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
buf = RNA_struct_name_get_alloc(&ptr, str, str_maxncpy, &buf_len);
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
else {
BLI_assert(0);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (buf == nullptr) {
[#20987] A small bug in logic editor string was used, uninitialized.
2010-02-08 19:24:13 +00:00
str[0] = '\0';
RNA * RNA_struct_name_get_alloc function to get the name from a pointer, instead of having to deal with name property. * CTX_data_pointer_get_type to get data from context with a check for the RNA type.
2009-06-24 14:03:55 +00:00
}
Cleanup: remove redundant NULL checks
2019-10-28 00:36:23 +11:00
else if (buf != str) {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_assert(str_maxncpy <= buf_len + 1);
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
/* string was too long, we have to truncate */
Expose button UTF8 check in UI_interface.h Used in following commit.
2019-09-04 16:19:48 +02:00
if (UI_but_is_utf8(but)) {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_strncpy_utf8(str, buf, str_maxncpy);
Fix UI crash entering very long strings Strings exceeding UI_MAX_DRAW_STR weren't null terminated.
2015-09-18 16:30:47 +10:00
}
else {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_strncpy(str, buf, str_maxncpy);
Fix UI crash entering very long strings Strings exceeding UI_MAX_DRAW_STR weren't null terminated.
2015-09-18 16:30:47 +10:00
}
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
MEM_freeN((void *)buf);
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
else if (ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU)) {
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
/* string */
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_strncpy(str, but->poin, str_maxncpy);
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
return;
}
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
else if (ui_but_anim_expression_get(but, str, str_maxncpy)) {
style cleanup
2012-10-14 13:08:19 +00:00
/* driver expression */
}
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
else {
2.5: Couple of small fun features * Text window font size now supports full range 8-32, instead of just 12 and 15. I added BLF_fixed_width to get the character width of a fixed size font. * Buttons do undo push on change again. * Animated/Keyframe/Driver colors are now themable, with blend value to blend with original color. Set this to 0.5 now to give colors less constrast. * Fix tooltip popping up with RMB menu open, and missing redraw. * Autokeyframe now works for buttons. * Driver expressions can be edited in place in a button now. (still some refresh issues). * Also made python driver default for the Add Driver function in the RMB button. This way you don't have to open a Graph editor if you just want to type an expression. Also, the default expression then is the current value. * Tooltips now show some extra info, not sure what is good to have, but currently I added: * Shortcut key for operator buttons. * Python struct & property name for RNA buttons. * Expression for driven values. * Value for text/search/pointer buttons.
2009-07-12 02:06:15 +00:00
/* number editing */
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const double value = ui_but_value_get(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ui_but_is_float(but)) {
RNA: display exact integer values without fraction if step is integer. Display exact integer values of a floating point fields without a fraction if the step is also an exact integer. This is intended for cases when the value can technically be fractional, but most commonly is supposed to be integer. This handling is not applied if the field has any unit except frames, because integer values aren't special for quantities like length. The fraction is discarded in the normal display mode and when copying the value to clipboard, but not when editing to remind the user that the field allows fractions. Differential Revision: https://developer.blender.org/D13753
2021-12-26 18:09:19 +03:00
int prec = float_precision;
if (float_precision == -1) {
prec = ui_but_calc_float_precision(but, value);
}
else if (!use_exp_float && ui_but_hide_fraction(but, value)) {
prec = 0;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ui_but_is_unit(but)) {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
ui_get_but_string_unit(but, str, str_maxncpy, value, false, prec);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
else if (subtype == PROP_FACTOR) {
if (U.factor_display_type == USER_FACTOR_AS_FACTOR) {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_snprintf(str, str_maxncpy, "%.*f", prec, value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
else {
Cleanup: use std::min/max instead of MIN2/MAX2 macros
2023-11-07 16:33:19 +11:00
BLI_snprintf(str, str_maxncpy, "%.*f", std::max(0, prec - 2), value * 100);
user interface units, off by default. - currently only distances work. - user preferences, edit section to set the units and scale. - option to display pairs (nicer for imperial display?) - support for evaluating multiple comma separated values eg: 2',11" ..or.. 5ft, 4mil - comma separated expressions/values accumulate 1+1,2**3,4cm/3 - attempted fast conversion from a value to a string so button drawing isn't too slow. * imperial long/short * - mile, mi - yard, yd - foot, ' - inch, " - thou, mil * metric long/short * kilometer, km meter, m centimeter, cm millimeter, mm micrometer, um nanometer, nm picometer, pm
2009-08-11 18:53:01 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
use less verbose string formatting for units and interface.
2011-03-29 14:36:55 +00:00
else {
UI: Finalize old TODO in UI float number handling. Just enable some commented-out code from rB636289b755f6ce (disabled at that time because we were too close of 2.79 release...). Issue raised in D5486, thanks.
2019-08-15 11:07:44 +02:00
const int int_digits_num = integer_digits_f(value);
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
if (use_exp_float) {
Fix multi-units drawing re precision handling. This is still far from prefect, but yet much better than what we had so far (more consistent with inheritent precision available in floats). Note that this fixes some (currently commented out) units unittests, and requires adjusting some others, will be done in next commit.
2017-08-01 16:35:07 +02:00
if (int_digits_num < -6 || int_digits_num > 12) {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_snprintf(str, str_maxncpy, "%.*g", prec, value);
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
if (r_use_exp_float) {
*r_use_exp_float = true;
}
}
else {
Fix multi-units drawing re precision handling. This is still far from prefect, but yet much better than what we had so far (more consistent with inheritent precision available in floats). Note that this fixes some (currently commented out) units unittests, and requires adjusting some others, will be done in next commit.
2017-08-01 16:35:07 +02:00
prec -= int_digits_num;
Fix two issues with recent changes to number display while editing them. * Numbers with units (especially, angles) where not handled correctly regarding number of significant digits (spotted by @brecht in T52222 comment, thanks). * Zero value has no valid log, need to take that into account!
2017-07-31 15:40:26 +02:00
CLAMP(prec, 0, UI_PRECISION_FLOAT_MAX);
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_snprintf(str, str_maxncpy, "%.*f", prec, value);
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
}
}
else {
Fix multi-units drawing re precision handling. This is still far from prefect, but yet much better than what we had so far (more consistent with inheritent precision available in floats). Note that this fixes some (currently commented out) units unittests, and requires adjusting some others, will be done in next commit.
2017-08-01 16:35:07 +02:00
prec -= int_digits_num;
CLAMP(prec, 0, UI_PRECISION_FLOAT_MAX);
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_snprintf(str, str_maxncpy, "%.*f", prec, value);
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
}
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
}
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
else {
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
BLI_snprintf(str, str_maxncpy, "%d", int(value));
Fix bad loss of precision when manually editing values in numbuttons. While drawing nice 'rounded' values is OK also for 'low precision' editing like dragging and such, it's quite an issue when you type in a precise value, validate, edit again the value, and find a rounded version of it instead of what you typed in! So now, *only when entering textedit of num buttons*, we always get the highest reasonable precision for floats (and use exponential notation when values are too low or too high, to avoid tremendous amounts of zero's).
2017-07-17 18:22:12 +02:00
}
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +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
}
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
void ui_but_string_get(uiBut *but, char *str, const size_t str_maxncpy)
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +00:00
{
Cleanup: use of the term 'len' & 'maxlen' Only use the term len & maxlen when they represent the length & maximum length of a string. Instead of the available bytes to use. Also include the data they're referencing as a suffix, otherwise it's not always clear what the length is in reference to.
2023-05-07 15:22:58 +10:00
ui_but_string_get_ex(but, str, str_maxncpy, -1, false, nullptr);
fix [#34490] Copy and paste floating point number fields losses precision - copy now gets up to 6 decimal places - copy and UI float button editing now strip zeros: 1.000 -> 1.0
2013-03-04 04:21:51 +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
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
char *ui_but_string_get_dynamic(uiBut *but, int *r_str_size)
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
char *str = nullptr;
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
*r_str_size = 1;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
if (but->rnaprop && ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU)) {
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const PropertyType type = RNA_property_type(but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
if (type == PROP_STRING) {
/* RNA string */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
str = RNA_property_string_get_alloc(&but->rnapoin, but->rnaprop, nullptr, 0, r_str_size);
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
(*r_str_size) += 1;
}
else if (type == PROP_ENUM) {
/* RNA enum */
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int value = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
const char *value_id;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (!RNA_property_enum_name(static_cast<bContext *>(but->block->evil_C),
&but->rnapoin,
but->rnaprop,
value,
&value_id))
{
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
value_id = "";
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
*r_str_size = strlen(value_id) + 1;
str = BLI_strdupn(value_id, *r_str_size);
}
else if (type == PROP_POINTER) {
/* RNA pointer */
PointerRNA ptr = RNA_property_pointer_get(&but->rnapoin, but->rnaprop);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
str = RNA_struct_name_get_alloc(&ptr, nullptr, 0, r_str_size);
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
(*r_str_size) += 1;
}
else {
BLI_assert(0);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
}
else {
BLI_assert(0);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (UNLIKELY(str == nullptr)) {
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
/* should never happen, paranoid check */
*r_str_size = 1;
str = BLI_strdup("");
BLI_assert(0);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
return str;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: improve errors when evaluating a number button fails Showing the Python error without any explanation is often not enough information and doesn't hint that the error was in the user input. The error report from a invalid expression such as '..1' used to be: ('invalid syntax', ('<string>', 1, 1, '..1')) Now reads: Error evaluating number, see Info editor for details: invalid syntax Address issue raised by T78913.
2020-07-27 13:46:58 +10:00
/**
Cleanup: move Python script execution into BPY_extern_run.h This commit renames 'execute' to 'run' because: - This follows Python's "PyRun" which these functions wrap. - Execution functions can use either exec/eval modes, making naming awkward (for future API refactoring).
2020-08-17 17:46:06 +10:00
* Report a generic error prefix when evaluating a string with #BPY_run_string_as_number
UI: improve errors when evaluating a number button fails Showing the Python error without any explanation is often not enough information and doesn't hint that the error was in the user input. The error report from a invalid expression such as '..1' used to be: ('invalid syntax', ('<string>', 1, 1, '..1')) Now reads: Error evaluating number, see Info editor for details: invalid syntax Address issue raised by T78913.
2020-07-27 13:46:58 +10:00
* as the Python error on its own doesn't provide enough context.
*/
I18n: Go over TIP_ and IFACE_ usages, change to RPT_ when relevant The previous commit introduced a new `RPT_()` macro to translate strings which are not tooltips or regular interface elements, but longer reports or statuses. This commit uses the new macro to translate many strings all over the UI. Most of it is a simple replace from `TIP_()` or `IFACE_()` to `RPT_()`, but there are some additional changes: - A few translations inside `BKE_report()` are removed altogether because they are already handled by the translation system. - Messages inside `UI_but_disable()` are no longer translated manually, but they are handled by a new regex in the translation system. Pull Request: https://projects.blender.org/blender/blender/pulls/116804 Pull Request: https://projects.blender.org/blender/blender/pulls/116804
2024-01-11 19:49:03 +01:00
#define UI_NUMBER_EVAL_ERROR_PREFIX RPT_("Error evaluating number, see Info editor for details")
UI: improve errors when evaluating a number button fails Showing the Python error without any explanation is often not enough information and doesn't hint that the error was in the user input. The error report from a invalid expression such as '..1' used to be: ('invalid syntax', ('<string>', 1, 1, '..1')) Now reads: Error evaluating number, see Info editor for details: invalid syntax Address issue raised by T78913.
2020-07-27 13:46:58 +10:00
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
static bool ui_number_from_string_units(
bContext *C, const char *str, const int unit_type, const UnitSettings *unit, double *r_value)
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
char *error = nullptr;
PyAPI: support retrieving the exception when running a string - Optionally get the error as a single line. - Support access the error as an allocated string. - PyC_ExceptionBuffer_Simple was always printing to the `stdout` while PyC_ExceptionBuffer didn't, now either print to the output. Without this, callers are unable to do anything with the error string.
2021-04-12 21:39:56 +10:00
const bool ok = user_string_to_number(C, str, unit, unit_type, r_value, true, &error);
if (error) {
ReportList *reports = CTX_wm_reports(C);
BKE_reportf(reports, RPT_ERROR, "%s: %s", UI_NUMBER_EVAL_ERROR_PREFIX, error);
MEM_freeN(error);
}
return ok;
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
}
static bool ui_number_from_string_units_with_but(bContext *C,
const char *str,
const uiBut *but,
double *r_value)
{
const int unit_type = RNA_SUBTYPE_UNIT_VALUE(UI_but_unit_type_get(but));
Units: Support for fixed units Users can select the main unit they want to use now. Previously the displayed unit always depended on the magnitude of the value. The old behavior can be restored by switching to the "Adaptive" mode for length, mass and time units. Meters, kilograms and seconds are the default units for new and old scenes. The selected unit is also the default unit for user input. E.g. if cm is selected, whenever the user inputs a unitless number into a field of type length, it will be interpreted as cm. Reviewer: brecht Differential: https://developer.blender.org/D3740
2018-10-03 10:20:16 +02:00
const UnitSettings *unit = but->block->unit;
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
return ui_number_from_string_units(C, str, unit_type, unit, r_value);
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
}
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
static bool ui_number_from_string(bContext *C, const char *str, double *r_value)
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
{
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
bool ok;
modify number button copy/paste to work as if you enter the button, select text, type into another button the same value. This means you can copy/paste units and python expressions.
2012-01-20 22:32:47 +00:00
#ifdef WITH_PYTHON
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
BPy_RunErrInfo err_info = {};
err_info.reports = CTX_wm_reports(C);
err_info.report_prefix = UI_NUMBER_EVAL_ERROR_PREFIX;
ok = BPY_run_string_as_number(C, nullptr, str, &err_info, r_value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
#else
CMake: support building without Python Resolve linking issues, warnings.
2019-11-25 15:45:03 +11:00
UNUSED_VARS(C);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
*r_value = atof(str);
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
ok = true;
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
#endif
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
return ok;
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
modify number button copy/paste to work as if you enter the button, select text, type into another button the same value. This means you can copy/paste units and python expressions.
2012-01-20 22:32:47 +00:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
static bool ui_number_from_string_factor(bContext *C, const char *str, double *r_value)
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int len = strlen(str);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
if (BLI_strn_endswith(str, "%", len)) {
char *str_new = BLI_strdupn(str, len - 1);
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const bool success = ui_number_from_string(C, str_new, r_value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
MEM_freeN(str_new);
*r_value /= 100.0;
return success;
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (!ui_number_from_string(C, str, r_value)) {
return false;
}
if (U.factor_display_type == USER_FACTOR_AS_PERCENTAGE) {
*r_value /= 100.0;
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return true;
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
static bool ui_number_from_string_percentage(bContext *C, const char *str, double *r_value)
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int len = strlen(str);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
if (BLI_strn_endswith(str, "%", len)) {
char *str_new = BLI_strdupn(str, len - 1);
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const bool success = ui_number_from_string(C, str_new, r_value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
MEM_freeN(str_new);
return success;
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return ui_number_from_string(C, str, r_value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
modify number button copy/paste to work as if you enter the button, select text, type into another button the same value. This means you can copy/paste units and python expressions.
2012-01-20 22:32:47 +00:00
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
bool ui_but_string_eval_number(bContext *C, const uiBut *but, const char *str, double *r_value)
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
{
if (str[0] == '\0') {
*r_value = 0.0;
return true;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
if (ui_but_is_float(but)) {
if (ui_but_is_unit(but)) {
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
return ui_number_from_string_units_with_but(C, str, but, r_value);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (subtype == PROP_FACTOR) {
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
return ui_number_from_string_factor(C, str, r_value);
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (subtype == PROP_PERCENTAGE) {
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
return ui_number_from_string_percentage(C, str, r_value);
}
return ui_number_from_string(C, str, r_value);
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return ui_number_from_string(C, str, r_value);
fix for own mistake in recent commit: [#27000] Spotlight spot shape size, lamp object data - numerical entries are interpreted as radians though displayed in degrees in SVN 36199 now apply units after python evaluation for unit buttons.
2011-04-18 03:27:15 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bool ui_but_string_set(bContext *C, uiBut *but, const char *str)
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
{
UI: Add template_search (version of template_ID for non-IDs) Adds a version of template_ID that can be used for non-ID properties. The property to search for and the collection to search in has to be passed to it. Like template_ID it also takes arguments to define a 'new' and 'unlink' operator. They will be displayed as icon-only buttons then. Also added a version that can display preview thumbnails. Had to do some additional changes to make text-buttons support displaying/modifying empty RNA properties. This will be needed for workspaces, see D2451. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D2666
2017-05-12 01:42:42 +02:00
if (but->rnaprop && but->rnapoin.data && ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU)) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_property_editable(&but->rnapoin, but->rnaprop)) {
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const PropertyType type = RNA_property_type(but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (type == PROP_STRING) {
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
/* RNA string */
RNA_property_string_set(&but->rnapoin, but->rnaprop, str);
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (type == PROP_POINTER) {
Code Cleanup: remove redundant NULL checks and add function attributes
2014-01-20 11:13:53 +11:00
if (str[0] == '\0') {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, PointerRNA_NULL, nullptr);
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
UI: * Added Constraints template and Add Constraint operator. * Added toggle=True/False parameter to uiItemR, to get a toggle button (actual button) rather than an "option" button (checkbox) * Added OPTION/OPTIONN button type, to distinguish with TOG/TOGN. RNA: * Make all modifier pointers editable, including correct updates. * Added notifiers and updates to constraints. * Fix a stack corruption, pointed out by Andrea, and potentially causing crashes.
2009-05-27 00:03:49 +00:00
}
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiButSearch *search_but = (but->type == UI_BTYPE_SEARCH_MENU) ? (uiButSearch *)but :
nullptr;
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
/* RNA pointer */
PointerRNA rptr;
/* This is kind of hackish, in theory think we could only ever use the second member of
Cleanup: use doxygen comments, correct spelling Also move eDupli_ID_Flags doc-string to it's declaration.
2022-03-01 09:09:24 +11:00
* this if/else, since #ui_searchbox_apply() is supposed to always set that pointer when
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
* we are storing pointers... But keeping str search first for now,
* to try to break as little as possible existing code. All this is band-aids anyway.
Cleanup: use doxygen comments, correct spelling Also move eDupli_ID_Flags doc-string to it's declaration.
2022-03-01 09:09:24 +11:00
* Fact remains, using `editstr` as main 'reference' over whole search button thingy
* is utterly weak and should be redesigned IMHO, but that's not a simple task. */
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
if (search_but && search_but->rnasearchprop &&
RNA_property_collection_lookup_string(
&search_but->rnasearchpoin, search_but->rnasearchprop, str, &rptr))
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, rptr, nullptr);
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
}
Fix potential null pointer de-reference Refactoring &
2024-04-01 22:10:27 +11:00
else if (search_but && search_but->item_active != nullptr) {
RNA: return PointerRNA from rna create functions There are a couple of functions that create rna pointers. For example `RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those take an output parameter `r_ptr` as last argument. This patch changes it so that the functions actually return a` PointerRNA` instead of using the output parameters. This has a few benefits: * Output parameters should only be used when there is an actual benefit. Otherwise, one should default to returning the value. * It's simpler to use the API in the large majority of cases (note that this patch reduces the number of lines of code). * It allows the `PointerRNA` to be const on the call-site, if that is desired. No performance regression has been measured in production files. If one of these functions happened to be called in a hot loop where there is a regression, the solution should be to use an inline function there which allows the compiler to optimize it even better. Pull Request: https://projects.blender.org/blender/blender/pulls/111976
2023-09-06 00:48:50 +02:00
rptr = RNA_pointer_create(nullptr,
RNA_property_pointer_type(&but->rnapoin, but->rnaprop),
search_but->item_active);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, rptr, nullptr);
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return true;
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (type == PROP_ENUM) {
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
int value;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (RNA_property_enum_value(static_cast<bContext *>(but->block->evil_C),
&but->rnapoin,
but->rnaprop,
str,
&value))
{
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
RNA_property_enum_set(&but->rnapoin, but->rnaprop, value);
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
}
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
BLI_assert(0);
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
}
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
else if (but->type == UI_BTYPE_TAB) {
if (but->rnaprop && but->custom_data) {
StructRNA *ptr_type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
PropertyRNA *prop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
/* uiBut.custom_data points to data this tab represents (e.g. workspace).
* uiBut.rnapoin/prop store an active value (e.g. active workspace). */
RNA: return PointerRNA from rna create functions There are a couple of functions that create rna pointers. For example `RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those take an output parameter `r_ptr` as last argument. This patch changes it so that the functions actually return a` PointerRNA` instead of using the output parameters. This has a few benefits: * Output parameters should only be used when there is an actual benefit. Otherwise, one should default to returning the value. * It's simpler to use the API in the large majority of cases (note that this patch reduces the number of lines of code). * It allows the `PointerRNA` to be const on the call-site, if that is desired. No performance regression has been measured in production files. If one of these functions happened to be called in a hot loop where there is a regression, the solution should be to use an inline function there which allows the compiler to optimize it even better. Pull Request: https://projects.blender.org/blender/blender/pulls/111976
2023-09-06 00:48:50 +02:00
PointerRNA ptr = RNA_pointer_create(but->rnapoin.owner_id, ptr_type, but->custom_data);
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
prop = RNA_struct_name_property(ptr_type);
if (RNA_property_editable(&ptr, prop)) {
RNA_property_string_set(&ptr, prop, str);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
else if (but->type == UI_BTYPE_TEXT) {
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
/* string */
Fix T61696: Filepath buttons not accepting empty values The reported case was with the render output filename, however the same was happening for file open. Bug introduced on c20c203b82260c06888c2a535c08ec383923ee8a. I can't find in the original commit any reasoning for the change that introduced this bug.
2019-02-19 17:24:10 -03:00
if (!but->poin) {
UI: Add template_search (version of template_ID for non-IDs) Adds a version of template_ID that can be used for non-ID properties. The property to search for and the collection to search in has to be passed to it. Like template_ID it also takes arguments to define a 'new' and 'unlink' operator. They will be displayed as icon-only buttons then. Also added a version that can display preview thumbnails. Had to do some additional changes to make text-buttons support displaying/modifying empty RNA properties. This will be needed for workspaces, see D2451. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D2666
2017-05-12 01:42:42 +02:00
str = "";
}
Expose button UTF8 check in UI_interface.h Used in following commit.
2019-09-04 16:19:48 +02:00
else if (UI_but_is_utf8(but)) {
UI: Add template_search (version of template_ID for non-IDs) Adds a version of template_ID that can be used for non-ID properties. The property to search for and the collection to search in has to be passed to it. Like template_ID it also takes arguments to define a 'new' and 'unlink' operator. They will be displayed as icon-only buttons then. Also added a version that can display preview thumbnails. Had to do some additional changes to make text-buttons support displaying/modifying empty RNA properties. This will be needed for workspaces, see D2451. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D2666
2017-05-12 01:42:42 +02:00
BLI_strncpy_utf8(but->poin, str, but->hardmax);
}
else {
BLI_strncpy(but->poin, str, but->hardmax);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
UI: remove UI_BTYPE_SEARCH_MENU_UNLINK Internal change only, use UI_BTYPE_SEARCH_MENU with an unlink flag instead. They are really the same button type, one just happens to have the option to unlink.
2015-03-24 15:05:27 +11:00
else if (but->type == UI_BTYPE_SEARCH_MENU) {
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
/* string */
BLI_strncpy(but->poin, str, but->hardmax);
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (ui_but_anim_expression_set(but, str)) {
2.5: Couple of small fun features * Text window font size now supports full range 8-32, instead of just 12 and 15. I added BLF_fixed_width to get the character width of a fixed size font. * Buttons do undo push on change again. * Animated/Keyframe/Driver colors are now themable, with blend value to blend with original color. Set this to 0.5 now to give colors less constrast. * Fix tooltip popping up with RMB menu open, and missing redraw. * Autokeyframe now works for buttons. * Driver expressions can be edited in place in a button now. (still some refresh issues). * Also made python driver default for the Add Driver function in the RMB button. This way you don't have to open a Graph editor if you just want to type an expression. Also, the default expression then is the current value. * Tooltips now show some extra info, not sure what is good to have, but currently I added: * Shortcut key for operator buttons. * Python struct & property name for RNA buttons. * Expression for driven values. * Value for text/search/pointer buttons.
2009-07-12 02:06:15 +00:00
/* driver expression */
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
2.5: Couple of small fun features * Text window font size now supports full range 8-32, instead of just 12 and 15. I added BLF_fixed_width to get the character width of a fixed size font. * Buttons do undo push on change again. * Animated/Keyframe/Driver colors are now themable, with blend value to blend with original color. Set this to 0.5 now to give colors less constrast. * Fix tooltip popping up with RMB menu open, and missing redraw. * Autokeyframe now works for buttons. * Driver expressions can be edited in place in a button now. (still some refresh issues). * Also made python driver default for the Add Driver function in the RMB button. This way you don't have to open a Graph editor if you just want to type an expression. Also, the default expression then is the current value. * Tooltips now show some extra info, not sure what is good to have, but currently I added: * Shortcut key for operator buttons. * Python struct & property name for RNA buttons. * Expression for driven values. * Value for text/search/pointer buttons.
2009-07-12 02:06:15 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (str[0] == '#') {
Cleanup: spelling in comments
2021-07-05 12:47:46 +10:00
/* Shortcut to create new driver expression (versus immediate Python-execution). */
style cleanup: interface
2012-03-30 01:51:25 +00:00
return ui_but_anim_expression_create(but, str + 1);
First stages of easier "expressions" creation... It is now possible to create "scripted expression" drivers by simply clicking on some property, and typing some short Python expression prefixed with a '#'. This will result in a scripted expression driver, with the typed-in text being created. For example, you can click on X-Location of the default cube, and type: #sin(frame) and a new driver will be created for the x-location of the cube. This will use the current frame value, and modulate this with a sine wave. Do note though, that the current frame is a special case here. In the current implementation, a special "frame" driver variable, which references the current scene frame is created automatically, so that this simple and (assumed) common case will work straight out of the box. Future improvements: - Explore possibilities of semi-automated extraction of variables from such expressions, resulting in automated variable extraction. (Doing away with variables completely is definitely 100% off the agenda though) - Look into some ways of defining some shorthands for referencing local data (possibly related to variable extraction?)
2011-07-04 03:12:28 +00:00
}
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
else {
2.5: Couple of small fun features * Text window font size now supports full range 8-32, instead of just 12 and 15. I added BLF_fixed_width to get the character width of a fixed size font. * Buttons do undo push on change again. * Animated/Keyframe/Driver colors are now themable, with blend value to blend with original color. Set this to 0.5 now to give colors less constrast. * Fix tooltip popping up with RMB menu open, and missing redraw. * Autokeyframe now works for buttons. * Driver expressions can be edited in place in a button now. (still some refresh issues). * Also made python driver default for the Add Driver function in the RMB button. This way you don't have to open a Graph editor if you just want to type an expression. Also, the default expression then is the current value. * Tooltips now show some extra info, not sure what is good to have, but currently I added: * Shortcut key for operator buttons. * Python struct & property name for RNA buttons. * Expression for driven values. * Value for text/search/pointer buttons.
2009-07-12 02:06:15 +00:00
/* number editing */
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
double value;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: match call signature for UI unit number evaluation Also rename ui_but_string_set_eval_num to ui_but_string_eval_number as it doesn't set any of the buttons values.
2020-07-27 12:03:02 +10:00
if (ui_but_string_eval_number(C, but, str, &value) == false) {
WM: pass the window manager & window to WM_report_banner_show Avoid potential problems when the active window is known but not assigned to `wm->winactive`, where the first window would be used as a fallback. Instead, take a window argument, a fallback is still used as a last resort (when NULL).
2023-07-11 14:31:26 +10:00
WM_report_banner_show(CTX_wm_manager(C), CTX_wm_window(C));
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
change unit evaluation only to do try the units replacements if evaluating with python fails, in rare cases its possible a valid python expression could get units applied to it.
2011-04-17 12:47:20 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: avoid int cast before clamping number input Values outside int range would overflow.
2017-09-17 17:56:23 +10:00
if (!ui_but_is_float(but)) {
value = floor(value + 0.5);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
/* not that we use hard limits here */
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (value < double(but->hardmin)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
value = but->hardmin;
}
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (value > double(but->hardmax)) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
value = but->hardmax;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_value_set(but, value);
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return true;
UI: * Added support for RNA pointer buttons. It's like the existing ID pointer buttons but with an icon, and autocomplete works. There's some drawing issues currently but don't want to interfere with the refactoring here. Also todo is support for things like vertex groups or bones.
2009-03-30 17:31:37 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use bools in UI and WM code, quiet some shadow warnings, remove unused function uiEmboss()
2013-04-04 02:05:11 +00:00
return false;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
static double soft_range_round_up(double value, double max)
{
prevent floating point exceptions from being raised in soft_range_round_up/soft_range_round_down(), caused by log(0).
2012-11-07 11:28:50 +00:00
/* round up to .., 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, ..
* checking for 0.0 prevents floating point exceptions */
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const double newmax = (value != 0.0) ? pow(10.0, ceil(log(value) / M_LN10)) : 0.0;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (newmax * 0.2 >= max && newmax * 0.2 >= value) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
return newmax * 0.2;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (newmax * 0.5 >= max && newmax * 0.5 >= value) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
return newmax * 0.5;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return newmax;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
static double soft_range_round_down(double value, double max)
{
prevent floating point exceptions from being raised in soft_range_round_up/soft_range_round_down(), caused by log(0).
2012-11-07 11:28:50 +00:00
/* round down to .., 0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50, ..
* checking for 0.0 prevents floating point exceptions */
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const double newmax = (value != 0.0) ? pow(10.0, floor(log(value) / M_LN10)) : 0.0;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (newmax * 5.0 <= max && newmax * 5.0 <= value) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
return newmax * 5.0;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (newmax * 2.0 <= max && newmax * 2.0 <= value) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
return newmax * 2.0;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return newmax;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
UI: fix buttons ranges not properly updated when tabbing to next/previous button This was reported for the FCurve modifier restrict ranges, but might fail elsewhere, too. Reason is that the post_but has its range (hardmin/ hardmax etc) set before the updates to the active button take place, so changes here dont end up on the post_but (even though the RNA range function is properly called for a new defined button - new one is not the same as the post_but though). Now update the ranges on the post_but when that gets active. Fixes T78763 Maniphest Tasks: T78763 Differential Revision: https://developer.blender.org/D8265
2020-07-09 15:38:31 +02:00
void ui_but_range_set_hard(uiBut *but)
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (but->rnaprop == nullptr) {
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
return;
}
UI: fix buttons ranges not properly updated when tabbing to next/previous button This was reported for the FCurve modifier restrict ranges, but might fail elsewhere, too. Reason is that the post_but has its range (hardmin/ hardmax etc) set before the updates to the active button take place, so changes here dont end up on the post_but (even though the RNA range function is properly called for a new defined button - new one is not the same as the post_but though). Now update the ranges on the post_but when that gets active. Fixes T78763 Maniphest Tasks: T78763 Differential Revision: https://developer.blender.org/D8265
2020-07-09 15:38:31 +02:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
const PropertyType type = RNA_property_type(but->rnaprop);
UI: fix buttons ranges not properly updated when tabbing to next/previous button This was reported for the FCurve modifier restrict ranges, but might fail elsewhere, too. Reason is that the post_but has its range (hardmin/ hardmax etc) set before the updates to the active button take place, so changes here dont end up on the post_but (even though the RNA range function is properly called for a new defined button - new one is not the same as the post_but though). Now update the ranges on the post_but when that gets active. Fixes T78763 Maniphest Tasks: T78763 Differential Revision: https://developer.blender.org/D8265
2020-07-09 15:38:31 +02:00
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
if (type == PROP_INT) {
int imin, imax;
RNA_property_int_range(&but->rnapoin, but->rnaprop, &imin, &imax);
Fix T88762: UI using tab to enter next button could clamp the hard min/ max unneccessarily Since rB298d5eb66916 [which was needed to update buttons with custom property range functions correctly], using tab would always clamp (hardmin/hardmax) properties which were using FLT_MAX / INT_MAX as range in their property definitions. The clamping of rB298d5eb66916 was copied over from rB9b7f44ceb56c [where it was used for the softmin/softmax], and while the re-evaluation of hardmin/hardmax is needed for custom property range functions, the clamping should actually not take place. There are many properties using FLT_MAX / INT_MAX etc. and while it probably would be good to update these with ranges that make more sense -- not using FLT_MAX / INT_MAX would not have done the clamping here -- there should not be an arbitrary limit to these and they should stay as they are. Maniphest Tasks: T88762 Differential Revision: https://developer.blender.org/D11473
2021-06-03 13:12:51 +02:00
but->hardmin = imin;
but->hardmax = imax;
Cleanup: Decrease indentation by returning early Where the if statement was just a check for an error or an unhandled condition and there are no else statements, the rest of the function doesn't need to be indented.
2020-09-25 15:51:56 -05:00
}
else if (type == PROP_FLOAT) {
float fmin, fmax;
RNA_property_float_range(&but->rnapoin, but->rnaprop, &fmin, &fmax);
Fix T88762: UI using tab to enter next button could clamp the hard min/ max unneccessarily Since rB298d5eb66916 [which was needed to update buttons with custom property range functions correctly], using tab would always clamp (hardmin/hardmax) properties which were using FLT_MAX / INT_MAX as range in their property definitions. The clamping of rB298d5eb66916 was copied over from rB9b7f44ceb56c [where it was used for the softmin/softmax], and while the re-evaluation of hardmin/hardmax is needed for custom property range functions, the clamping should actually not take place. There are many properties using FLT_MAX / INT_MAX etc. and while it probably would be good to update these with ranges that make more sense -- not using FLT_MAX / INT_MAX would not have done the clamping here -- there should not be an arbitrary limit to these and they should stay as they are. Maniphest Tasks: T88762 Differential Revision: https://developer.blender.org/D11473
2021-06-03 13:12:51 +02:00
but->hardmin = fmin;
but->hardmax = fmax;
UI: fix buttons ranges not properly updated when tabbing to next/previous button This was reported for the FCurve modifier restrict ranges, but might fail elsewhere, too. Reason is that the post_but has its range (hardmin/ hardmax etc) set before the updates to the active button take place, so changes here dont end up on the post_but (even though the RNA range function is properly called for a new defined button - new one is not the same as the post_but though). Now update the ranges on the post_but when that gets active. Fixes T78763 Maniphest Tasks: T78763 Differential Revision: https://developer.blender.org/D8265
2020-07-09 15:38:31 +02:00
}
}
void ui_but_range_set_soft(uiBut *but)
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
{
Cleanup: move public doc-strings into headers for 'editors' Ref T92709
2021-12-09 00:55:11 +11:00
/* This could be split up into functions which handle arrays and not. */
Cleanup: Spelling Mistakes This patch fixes many minor spelling mistakes, all in comments or console output. Mostly contractions like can't, won't, don't, its/it's, etc. Differential Revision: https://developer.blender.org/D11663 Reviewed by Harley Acheson
2021-06-22 10:42:32 -07:00
/* Ideally we would not limit this, but practically it's more than
* enough. Worst case is very long vectors won't use a smart soft-range,
spelling cleanup
2012-03-18 07:38:51 +00:00
* which isn't so bad. */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
const PropertyType type = RNA_property_type(but->rnaprop);
Fix alpha transparency slider range being influenced by RGB values For buttons that edit array properties, the soft min/max and slider ranges are based on the range of all values in the array. However for alpha this does not make much sense, the only reasonable range is 0..1 even when there are RGB values larger than 1. So treat alpha as an individual property.
2021-01-27 15:00:27 +01:00
const PropertySubType subtype = RNA_property_subtype(but->rnaprop);
Cleanup: spelling & punctuation in comments Also remove some unhelpful/redundant comments.
2023-09-14 13:25:24 +10:00
double softmin, softmax;
// double step, precision; /* UNUSED. */
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
double value_min;
double value_max;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix #20831: setting shadowbuffersize to 10240 only possible via typing it in.
2010-01-26 17:14:13 +00:00
/* clamp button range to something reasonable in case
* we get -inf/inf from RNA properties */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (type == PROP_INT) {
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
const bool is_array = RNA_property_array_check(but->rnaprop);
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
int imin, imax, istep;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
RNA_property_int_ui_range(&but->rnapoin, but->rnaprop, &imin, &imax, &istep);
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = (imin == INT_MIN) ? -1e4 : imin;
softmax = (imin == INT_MAX) ? 1e4 : imax;
Cleanup: full sentences in comments, improve comment formatting
2021-06-26 21:35:18 +10:00
// step = istep; /* UNUSED */
// precision = 1; /* UNUSED */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
if (is_array) {
fix [#27673] Value sliders >1 do not represent numerical ratios right the soft limits for array buttons not take into account the min/max of all array elements
2011-06-16 06:47:54 +00:00
int value_range[2];
RNA_property_int_get_array_range(&but->rnapoin, but->rnaprop, value_range);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value_min = double(value_range[0]);
value_max = double(value_range[1]);
fix [#27673] Value sliders >1 do not represent numerical ratios right the soft limits for array buttons not take into account the min/max of all array elements
2011-06-16 06:47:54 +00:00
}
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
else {
Fix alpha transparency slider range being influenced by RGB values For buttons that edit array properties, the soft min/max and slider ranges are based on the range of all values in the array. However for alpha this does not make much sense, the only reasonable range is 0..1 even when there are RGB values larger than 1. So treat alpha as an individual property.
2021-01-27 15:00:27 +01:00
value_min = value_max = ui_but_value_get(but);
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
}
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (type == PROP_FLOAT) {
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
const bool is_array = RNA_property_array_check(but->rnaprop);
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
float fmin, fmax, fstep, fprecision;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
RNA_property_float_ui_range(&but->rnapoin, but->rnaprop, &fmin, &fmax, &fstep, &fprecision);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
softmin = (fmin == -FLT_MAX) ? float(-1e4) : fmin;
softmax = (fmax == FLT_MAX) ? float(1e4) : fmax;
Cleanup: full sentences in comments, improve comment formatting
2021-06-26 21:35:18 +10:00
// step = fstep; /* UNUSED */
// precision = fprecision; /* UNUSED */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix alpha transparency slider range being influenced by RGB values For buttons that edit array properties, the soft min/max and slider ranges are based on the range of all values in the array. However for alpha this does not make much sense, the only reasonable range is 0..1 even when there are RGB values larger than 1. So treat alpha as an individual property.
2021-01-27 15:00:27 +01:00
/* Use shared min/max for array values, except for color alpha. */
if (is_array && !(subtype == PROP_COLOR && but->rnaindex == 3)) {
fix [#27673] Value sliders >1 do not represent numerical ratios right the soft limits for array buttons not take into account the min/max of all array elements
2011-06-16 06:47:54 +00:00
float value_range[2];
RNA_property_float_get_array_range(&but->rnapoin, but->rnaprop, value_range);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value_min = double(value_range[0]);
value_max = double(value_range[1]);
fix [#27673] Value sliders >1 do not represent numerical ratios right the soft limits for array buttons not take into account the min/max of all array elements
2011-06-16 06:47:54 +00:00
}
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
else {
Fix alpha transparency slider range being influenced by RGB values For buttons that edit array properties, the soft min/max and slider ranges are based on the range of all values in the array. However for alpha this does not make much sense, the only reasonable range is 0..1 even when there are RGB values larger than 1. So treat alpha as an individual property.
2021-01-27 15:00:27 +01:00
value_min = value_max = ui_but_value_get(but);
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
}
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
else {
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
return;
fix for bug where array buttons would use -1 index, causing an out-of-bounds check on an array. added assert so this wont happen again.
2013-03-06 16:32:05 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
/* if the value goes out of the soft/max range, adapt the range */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (value_min + 1e-10 < softmin) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (value_min < 0.0) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = -soft_range_round_up(-value_min, -softmin);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = soft_range_round_down(value_min, softmin);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (softmin < double(but->hardmin)) {
softmin = double(but->hardmin);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (value_max - 1e-10 > softmax) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (value_max < 0.0) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = -soft_range_round_down(-value_max, -softmax);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = soft_range_round_up(value_max, softmax);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
if (softmax > double(but->hardmax)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = but->hardmax;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->softmin = softmin;
but->softmax = softmax;
UI: * Added support for soft/hard range in the buttons code. Currently it works by only allowing to drag or click increment in the soft range, but typing a number value allows to go outside it. If the number is outside the soft range, the range will be extended, rounded to values like: .., 0.1, 0.2, 0.5, 1.0, 2.0, 5.0, 10.0, 20.0, 50.0, ..
2009-03-29 18:44:49 +00:00
}
fix [#36008] Can't set values higher than 1.0 in HSV colour picker (But can in RGB) - also some strange behavior
2013-07-09 04:00:56 +00:00
else if (but->poin && (but->pointype & UI_BUT_POIN_TYPES)) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
float value = ui_but_value_get(but);
UI: prevent softrange from becoming nan Quiets assert
2016-06-29 12:00:17 +10:00
if (isfinite(value)) {
CLAMP(value, but->hardmin, but->hardmax);
but->softmin = min_ff(but->softmin, value);
but->softmax = max_ff(but->softmax, value);
}
fix [#36008] Can't set values higher than 1.0 in HSV colour picker (But can in RGB) - also some strange behavior
2013-07-09 04:00:56 +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
}
/* ******************* Free ********************/
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
/**
* Free data specific to a certain button type.
* For now just do in a switch-case, we could instead have a callback stored in #uiBut and set that
* in #ui_but_alloc_info().
*/
static void ui_but_free_type_specific(uiBut *but)
{
switch (but->type) {
case UI_BTYPE_SEARCH_MENU: {
uiButSearch *search_but = (uiButSearch *)but;
UI: show recently selected items at the top of searches The goal is to make the search faster to use by dynamically adapting to the user. This can be achieved using the simple but common approach of showing recently selected items at the top. Note, that the "matching score" between the query and each search item still has precedence when determining the order. So the last used item is only at the top, if there is no other search item that matches the query better. Besides making the search generally faster to use, my hope is that this can also reduce the need for manually weighting search items in some places. This is because while the ordering might not be perfect the first time, it will always be once the user selected the element that should be at the top once. This patch includes: * Support for taking recent searches into account in string searching. * Keep track of a global list of recent searches. * Store recent searches on disk similar to recently opened files. * A new setting in the user preferences that allows disabling the functionality. This can be used if deterministic key strokes are required, e.g. for automated tests. In the future this could be improved in different ways: * Add some kind of separator in the search list to indicate which elements are at the top because they have been used recently. * Store the recent search items per search, instead of in a global list. This way it could adapt to the user even better. Pull Request: https://projects.blender.org/blender/blender/pulls/110828
2023-09-25 10:56:12 +02:00
MEM_SAFE_FREE(search_but->item_active_str);
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
if (search_but->arg_free_fn) {
search_but->arg_free_fn(search_but->arg);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
search_but->arg = nullptr;
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
}
break;
}
default:
break;
}
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
/* can be called with C==nullptr */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_but_free(const bContext *C, 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
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->opptr) {
RNA * Object has some more properties wrapped, mostly game related. * Scene frame changes now send a notifier. * Added functions to create/free operator properties for calling operators. This also simplifies some duplicated code that did this. Ideally though this kind of thing should use the properties pointer provided by buttons and keymap items. Example code: PointerRNA ptr; WM_operator_properties_create(&ptr, "SOME_OT_name"); RNA_int_set(&ptr, "value", 42); WM_operator_name_call(C, "SOME_OT_name", WM_OP_EXEC_DEFAULT, &ptr); WM_operator_properties_free(&ptr);
2009-01-01 20:44:40 +00:00
WM_operator_properties_free(but->opptr);
MEM_freeN(but->opptr);
UI: * Added support for defining properties for operator buttons, with uiButGetOperatorPtrRNA. Needed to cleanup a hack that was there for operator properties in RNA, now a separate OperatorProperties type is used for storing operator properties, instead of being part of the Operator type itself. * Allow selecting menu items with mouse release instead of press again. * Fix some cases with hanging tooltips in the UI.
2008-12-16 20:03:28 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->func_argN) {
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
MEM_freeN(but->func_argN);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: custom free function improvements This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits: * The caller can pass `null` to indicate that the value should not be freed. * Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible). I added `uiFreeArgFunc` and used it in other places where appropriate. Differential Revision: https://developer.blender.org/D11738
2021-06-30 17:27:54 +02:00
if (but->tip_arg_free) {
but->tip_arg_free(but->tip_arg);
UI: add optional tip callback to uiBut, and use it for per-item tooltips in UIList. When defined, uiBut->tip_func is called when button's tip is generated. This allows for advanced, dynamic generation of tooltips. For now, only used by UIList, which can now optionaly use a given string property of each item for its tooltip. Thanks to Campbell for the reviews!
2015-02-11 00:06:03 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Add UILayout.operator_menu_hold This is an operator button that opens a menu when the button is held.
2017-11-02 04:30:07 +11:00
if (but->hold_argN) {
MEM_freeN(but->hold_argN);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Input Placeholders Optional inline hint describing the expected value of an input field. Pull Request: #112104
2023-10-12 11:44:08 -07:00
if (but->placeholder) {
MEM_freeN(but->placeholder);
}
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
ui_but_free_type_specific(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->active) {
Fix #23433: crash with undo where a UI button was still active and accessing data that was freed.
2010-08-25 09:33:48 +00:00
/* XXX solve later, buttons should be free-able without context ideally,
correct indentation and some whitespace edits (no functional changes)
2011-11-11 13:09:14 +00:00
* however they may have open tooltips or popup windows, which need to
* be closed using a context pointer */
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (C) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_active_free(C, but);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
else {
Cleanup: remove redundant checks for known states
2024-03-29 10:29:47 +11:00
MEM_freeN(but->active);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if ((but->type == UI_BTYPE_IMAGE) && but->poin) {
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
IMB_freeImBuf((ImBuf *)but->poin);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move dragging code for buttons to own file Moves code for managing dragging data from buttons to a separate file. This way all this closely related code is in one location, making it easier to see how it all relates, and easier to find.
2022-05-31 15:06:57 +02:00
ui_but_drag_free(but);
UI: Refactor and improve buttton extra icons Without this patch there could only be one superimposed icon and the operators were hard coded for the button types. This keeps the previous, sort of predefined extra icons working in a rather generic way, but allows adding specific ones for specific case through `UI_but_extra_operator_icon_set()`. Reviewed by: Campbell Barton Differential Revision: https://developer.blender.org/D5730
2019-09-09 16:34:16 +02:00
ui_but_extra_operator_icons_free(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
BLI_assert(UI_butstore_is_registered(but->block, but) == false);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
MEM_delete(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
}
Refactor: Add ability for UI block to own operator Instead of only referencing an existing one. This will be used for collection exporter and presets, to make sure the operator instance stays alive long enough for the preset to be able to be applied. Pull Request: https://projects.blender.org/blender/blender/pulls/120034
2024-03-28 20:40:59 +01:00
static void ui_block_free_active_operator(uiBlock *block)
{
if (block->ui_operator_free) {
/* This assumes the operator instance owns the pointer. This is not
* true for all operators by default, but it can be copied when needed. */
MEM_freeN(block->ui_operator->ptr);
MEM_freeN(block->ui_operator);
}
block->ui_operator_free = false;
block->ui_operator = nullptr;
}
void UI_block_set_active_operator(uiBlock *block, wmOperator *op, const bool free)
{
if (op != block->ui_operator) {
ui_block_free_active_operator(block);
block->ui_operator = op;
block->ui_operator_free = free;
}
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_free(const bContext *C, 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
{
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
UI_butstore_clear(block);
Cleanup: reduce variable scope when removing in a while loop
2023-08-03 18:23:49 +10:00
while (uiBut *but = static_cast<uiBut *>(BLI_pophead(&block->buttons))) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_free(C, 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
}
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (block->unit) {
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
MEM_freeN((void *)block->unit);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
Fix #28593: F6 operator redo could crash when editing buttons that use unit settings, these could get freed with the scene on undo/redo, make a copy now.
2011-09-22 14:55:39 +00:00
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (block->func_argN) {
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
MEM_freeN(block->func_argN);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
Refactor: Add ability for UI block to own operator Instead of only referencing an existing one. This will be used for collection exporter and presets, to make sure the operator instance stays alive long enough for the preset to be able to be applied. Pull Request: https://projects.blender.org/blender/blender/pulls/120034
2024-03-28 20:40:59 +01:00
ui_block_free_active_operator(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
BLI_freelistN(&block->saferct);
Fix T42208 color pickers are coupled. Decouple color picker hsv data from the whole block. Basically, each color picker now takes care of creating its own color picker role. For this bug report it can be seen that probably HSV is not the best space for gamma/lift/gain workflow because it is bounded at 1.0 but this is a separate issue.
2014-11-06 20:19:21 +01:00
BLI_freelistN(&block->color_pickers.list);
UI: Support C defined menu types to listen to notifiers Needed to dynamically load assets as menu items, see cf985180551d and 99e5024e97f1. The next commit will add the listener for the node add menu.
2022-11-01 17:36:36 +01:00
BLI_freelistN(&block->dynamic_listeners);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI: Tree-View API for easy creation of tree UIs This follows three main targets: * Make creation of new tree UIs easy. * Groundwork to generalize tree UIs (so e.g. Outliner, animation channels, asset catalogs and spreadsheet data-sets don't have to re-implement basic tree UI code) or even other data-view UIs. * Better separate data and UI state. E.g. with this, tree-item selection or the open/collapsed state can be stored on the UI level, rather than in data. (Asset Catalogs need this, storing UI state info in them is not an option.) In addition, the design should be well testable and could even be exposed to Python. Note that things will likely change in master still. E.g. the actually resulting UI isn't very nice visually yet. The design is documented here: https://wiki.blender.org/wiki/Source/Interface/Views Differential Revision: https://developer.blender.org/D12573
2021-09-23 18:56:29 +02:00
ui_block_free_views(block);
UI: Move button groups from layout to block level For a future patch (D9006) we need these groups for longer than just the the layout process, in order to differentiate buttons in panel headers. It may also be helpful in the future to have a way to access related buttons added in the same uiLayout.prop call. With this commit, the groups are stored in and destructed with the uiBlock.
2020-10-02 17:00:41 -05:00
UI: Use vector instead of linked list for block button groups This simplifies some memory management, ammortizes some of the many small allocations when building UI layouts, and simplifies the code that deals with the groups. `uiBlock` is no longer a trivial type. In my testing this saved a few ms when drawing a large node tree.
2022-12-18 21:45:32 -06:00
MEM_delete(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
}
UI: Support C defined menu types to listen to notifiers Needed to dynamically load assets as menu items, see cf985180551d and 99e5024e97f1. The next commit will add the listener for the node add menu.
2022-11-01 17:36:36 +01:00
void UI_block_listen(const uiBlock *block, const wmRegionListenerParams *listener_params)
{
Fix broken UI view notifier listening (UI views: https://wiki.blender.org/wiki/Source/Interface/Views) Noticed while working on asset UIs with views, when async loading of assets wouldn't trigger redraws.
2023-05-05 15:07:36 +02:00
/* Note that #uiBlock.active shouldn't be checked here, since notifier listening happens before
* drawing, so there are no active blocks at this point. */
UI: Support C defined menu types to listen to notifiers Needed to dynamically load assets as menu items, see cf985180551d and 99e5024e97f1. The next commit will add the listener for the node add menu.
2022-11-01 17:36:36 +01:00
LISTBASE_FOREACH (uiBlockDynamicListener *, listener, &block->dynamic_listeners) {
listener->listener_func(listener_params);
}
ui_block_views_listen(block, listener_params);
}
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
void UI_blocklist_update_window_matrix(const bContext *C, const ListBase *lb)
{
ARegion *region = CTX_wm_region(C);
wmWindow *window = CTX_wm_window(C);
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBlock *, block, lb) {
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
if (block->active) {
ui_update_window_matrix(window, region, block);
}
}
}
UI: Auto-scroll to keep active text buttons in view If a text button is activated that is not in view (i.e. scrolled away), the scrolling will now be adjusted to have it in view (with some small additional margin). While entering text, the view may also be updated should the button move out of view, for whatever reason. For the most part, this feature shouldn't be needed and won't kick in, except when a clicked on text button is partially out of view or very close to the region edge. It's however quite important for the previously committed feature, that is, pressing Ctrl+F to start searching in a UI list. The end of the list where the scroll button appears may not be in view. Plus while filtering the number of visible items changes so the scrolling has to be updated to keep the search button visible. Note that I disabled the auto-scrolling for when the text button spawned an additional popup, like for search-box buttons. That is because current code assumes the button to have a fixed position while the popup is open. There is no code to update the popup position together with the button/scrolling. I also think that the logic added here could be used in more places, e.g. for the "ensure file in view" logic the File Browser does.
2021-07-13 17:06:15 +02:00
void UI_blocklist_update_view_for_buttons(const bContext *C, const ListBase *lb)
{
LISTBASE_FOREACH (uiBlock *, block, lb) {
if (block->active) {
ui_but_update_view_for_active(C, block);
}
}
}
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
void UI_blocklist_draw(const bContext *C, const ListBase *lb)
{
Code Quality: Replace for loops with LISTBASE_FOREACH Note this only changes cases where the variable was declared inside the for loop. To handle it outside as well is a different challenge. Differential Revision: https://developer.blender.org/D7320
2020-04-03 19:15:01 +02:00
LISTBASE_FOREACH (uiBlock *, block, lb) {
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
if (block->active) {
UI_block_draw(C, block);
}
}
}
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
void UI_blocklist_free(const bContext *C, ARegion *region)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
ListBase *lb = &region->uiblocks;
Cleanup: reduce variable scope when removing in a while loop
2023-08-03 18:23:49 +10:00
while (uiBlock *block = static_cast<uiBlock *>(BLI_pophead(lb))) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_free(C, 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
}
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (region->runtime.block_name_map != nullptr) {
BLI_ghash_free(region->runtime.block_name_map, nullptr, nullptr);
region->runtime.block_name_map = nullptr;
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +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
}
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
void UI_blocklist_free_inactive(const bContext *C, ARegion *region)
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
{
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
ListBase *lb = &region->uiblocks;
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH_MUTABLE (uiBlock *, block, lb) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!block->handle) {
Cleanup: Remove unecessary double negative
2021-02-23 11:25:13 -06:00
if (block->active) {
block->active = false;
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
}
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
else {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (region->runtime.block_name_map != nullptr) {
uiBlock *b = static_cast<uiBlock *>(
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
BLI_ghash_lookup(region->runtime.block_name_map, block->name.c_str()));
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
if (b == block) {
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
BLI_ghash_remove(region->runtime.block_name_map, b->name.c_str(), nullptr, nullptr);
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
}
}
Cleanup: Remove unecessary double negative
2021-02-23 11:25:13 -06:00
BLI_remlink(lb, block);
UI_block_free(C, block);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
}
}
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_region_set(uiBlock *block, ARegion *region)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
ListBase *lb = &region->uiblocks;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBlock *oldblock = nullptr;
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
/* each listbase only has one block with this name, free block
* if is already there so it can be rebuilt from scratch */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (lb) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (region->runtime.block_name_map == nullptr) {
UI: Use a map for block name lookups Use a map to speed up search for UI block names. Time to redraw the node editor was decreased from around 75-120ms to 40-70ms in a tree with many Geometry Nodes. Differential Revision: https://developer.blender.org/D13225
2021-11-15 17:10:53 +01:00
region->runtime.block_name_map = BLI_ghash_str_new(__func__);
}
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
oldblock = (uiBlock *)BLI_ghash_lookup(region->runtime.block_name_map, block->name.c_str());
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
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
if (oldblock) {
Cleanup: Use bool instead of char
2021-02-22 13:18:49 -06:00
oldblock->active = false;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
oldblock->panel = nullptr;
oldblock->handle = nullptr;
UI: Panels * API and usage is basically the same still. * Panels were moved to region level. I first thought of keeping them at area level, but having them at region level it's simpler to handle events and do drawing, and also to integrate with view2d. They can still become area level overlapping regions, if we make a floating (or docked) region that can contain panels. * Added back a few panels from the scene buttons for testing. Issues still: * The view2d handling and alignment refresh of panels is not correct yet in the buttons window. * I did not yet bring back the block handlers system. It was basically a system that stored which panel was open and where the events for that panel would go. Just a few functions, but not sure how it fits in 2.5. * There was a case where dragging panels would not properly remove the window level handler, but could not redo anymore even though I don't think I fixed it. * Some text in the panels goes past the end of the button, that is due to the checkmark button drawing, not related to this commit. Other UI code changes: * Renamed interface.h to interface_intern.h for consistency. * Fixed some issues with freeing of blocks when they changed due to context. * uiDrawBlock now takes a context pointer (mostly for block drawextra).
2008-12-26 13:11:04 +00:00
}
remove BLI_streq() since it was hardly used, also replace string search with BLI_findstring().
2011-05-26 21:04:01 +00:00
/* at the beginning of the list! for dynamical menus/blocks */
BLI_addhead(lb, block);
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
BLI_ghash_reinsert(region->runtime.block_name_map,
const_cast<char *>(block->name.c_str()),
block,
nullptr,
nullptr);
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
}
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->oldblock = 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
}
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
uiBlock *UI_block_begin(const bContext *C, ARegion *region, std::string name, eUIEmbossType emboss)
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
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
wmWindow *window = CTX_wm_window(C);
Cleanup: Use canonical variable name
2020-09-25 15:54:25 -05:00
Scene *scene = CTX_data_scene(C);
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
UI: Use vector instead of linked list for block button groups This simplifies some memory management, ammortizes some of the many small allocations when building UI layouts, and simplifies the code that deals with the groups. `uiBlock` is no longer a trivial type. In my testing this saved a few ms when drawing a large node tree.
2022-12-18 21:45:32 -06:00
uiBlock *block = MEM_new<uiBlock>(__func__);
Cleanup: Use bool instead of char
2021-02-22 13:18:49 -06:00
block->active = true;
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
block->emboss = emboss;
style cleanup
2012-08-19 10:41:27 +00:00
block->evil_C = (void *)C; /* XXX */
Fix #28593: F6 operator redo could crash when editing buttons that use unit settings, these could get freed with the scene on undo/redo, make a copy now.
2011-09-22 14:55:39 +00:00
Cleanup: Use canonical variable name
2020-09-25 15:54:25 -05:00
if (scene) {
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
/* store display device name, don't lookup for transformations yet
* block could be used for non-color displays where looking up for transformation
* would slow down redraw, so only lookup for actual transform when it's indeed
* needed
*/
Cleanup: Use canonical variable name
2020-09-25 15:54:25 -05:00
STRNCPY(block->display_device, scene->display_settings.display_device);
Fix #28593: F6 operator redo could crash when editing buttons that use unit settings, these could get freed with the scene on undo/redo, make a copy now.
2011-09-22 14:55:39 +00:00
Cleanup: use a const pointer for unit-settings
2024-03-29 16:37:36 +11:00
/* Copy to avoid crash when scene gets deleted with UI still open. */
UnitSettings *unit = MEM_new<UnitSettings>(__func__);
memcpy(unit, &scene->unit, sizeof(scene->unit));
block->unit = unit;
store a pointer to the units system in the uiBlock since the button code was doing context lookups for the scene quite a lot.
2011-08-18 20:01:30 +00:00
}
Fix T58549, T56741: HSV color picker issues with Filmic view transform. In 2d655d3 the color picker was changed to use display space HSV values. This works ok for a simple sRGB EOTF, but fails with view transforms like Filmic where display space V 1.0 maps to RGB 16.292. Instead we now use the color_picking role from the OCIO config when converting from RGB to HSV in the color picker. This role is set to sRGB in the default OCIO config. This color space fits the following requirements: * It is approximately perceptually linear, so that the HSV numbers and the HSV cube/circle have an intuitive distribution. * It has the same gamut as the scene linear color space. * Color picking values 0..1 map to scene linear values in the 0..1 range, so that picked albedo values are energy conserving.
2018-12-13 15:59:58 +01:00
else {
STRNCPY(block->display_device, IMB_colormanagement_display_get_default_name());
}
Fix #28593: F6 operator redo could crash when editing buttons that use unit settings, these could get freed with the scene on undo/redo, make a copy now.
2011-09-22 14:55:39 +00:00
Cleanup: Store uiBlock name as std::string And change some adjacent code to benefit from the simplicity and constant time access to the length of the string.
2024-01-18 15:59:20 -05:00
block->name = std::move(name);
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
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (region) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_region_set(block, region);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
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
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
/* Set window matrix and aspect for region and OpenGL state. */
ui_update_window_matrix(window, region, 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
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
/* Tag as popup menu if not created within a region. */
if (!(region && region->visible)) {
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
block->auto_open = true;
UI: better support for dynamically sized regions in topbar. Dynamically sized regions in the topbar were flickering due to only updating their size after redraws. Now there is an optional layout() callback for all regions in an area to do UI layout first, then refresh the region layout, and then do the actual drawing for each region. Task T54753
2018-04-29 12:24:08 +02:00
block->flag |= UI_BLOCK_LOOP;
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
}
return block;
}
UI: Allow popover panels to register own notifier listeners This is necessary to let popovers redraw when asynchronously loading data. For example to display assets or asset catalogs as they get loaded. Needed for the asset shelf catalog selector popover. Menus already do the same to allow populating the menu with assets as they get loaded.
2023-09-26 18:37:28 +02:00
void ui_block_add_dynamic_listener(uiBlock *block,
void (*listener_func)(const wmRegionListenerParams *params))
{
uiBlockDynamicListener *listener = static_cast<uiBlockDynamicListener *>(
MEM_mallocN(sizeof(*listener), __func__));
listener->listener_func = listener_func;
BLI_addtail(&block->dynamic_listeners, listener);
}
Cleanup: Use enum for UI block emboss type
2021-07-05 14:52:21 -05:00
eUIEmbossType UI_block_emboss_get(uiBlock *block)
Outliner Visibility Update See T61578 for discussions and mockups. Visibility Options ================== We are adding more granular control over restriction columns in the outliner, exposing "indirect only" and "holdout" as options, and change the way users enable/disable collections in a viewlayer. We also rename the object viewport restriction to hide instance. So the options we have are: Collection ---------- * Render Visibility * Instance Visibility * Selectable (View) Layer Collection ----------------------- * Enable * Holdout * Indirect Only * Viewport Shortcuts ========= Isolate Collection ------------------ * Ctr + click isolates the collection. It turns all its parents and children "visible", and all the other collections "invisible". If ALL the collections were already properly set, we re-set the collections to their default value. Set Collection Inside Collections and Objects --------------------------------------------- * Shift + click: Set/unset inside collections and objects. We only set objects values as well when we are in View Layer mode and (obviously) when the objects have a matching property. Icons ===== Little reminder that we will need better icons for holdout, indirect only, and probably instanced (nothing wrong with the current, but it differs from the proposal when it is turned off). Also, we need to decide where do we want the modifier/bones/... icons to be (in which column) and ideally make sure their icons match the ones we use for collections/objects. At the moment those are using the screen icon, which is not being used by collections. Reviewers: brecht, billrey Subscribers: pablovazquez Differential Revision: https://developer.blender.org/D4823
2019-05-04 14:14:37 -03:00
{
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
return block->emboss;
Outliner Visibility Update See T61578 for discussions and mockups. Visibility Options ================== We are adding more granular control over restriction columns in the outliner, exposing "indirect only" and "holdout" as options, and change the way users enable/disable collections in a viewlayer. We also rename the object viewport restriction to hide instance. So the options we have are: Collection ---------- * Render Visibility * Instance Visibility * Selectable (View) Layer Collection ----------------------- * Enable * Holdout * Indirect Only * Viewport Shortcuts ========= Isolate Collection ------------------ * Ctr + click isolates the collection. It turns all its parents and children "visible", and all the other collections "invisible". If ALL the collections were already properly set, we re-set the collections to their default value. Set Collection Inside Collections and Objects --------------------------------------------- * Shift + click: Set/unset inside collections and objects. We only set objects values as well when we are in View Layer mode and (obviously) when the objects have a matching property. Icons ===== Little reminder that we will need better icons for holdout, indirect only, and probably instanced (nothing wrong with the current, but it differs from the proposal when it is turned off). Also, we need to decide where do we want the modifier/bones/... icons to be (in which column) and ideally make sure their icons match the ones we use for collections/objects. At the moment those are using the screen icon, which is not being used by collections. Reviewers: brecht, billrey Subscribers: pablovazquez Differential Revision: https://developer.blender.org/D4823
2019-05-04 14:14:37 -03:00
}
Cleanup: Use typedef for UI emboss type enum Previously both `char` and `int` were used to represent this enum. Differential Revision: https://developer.blender.org/D9903
2020-12-19 10:07:13 -06:00
void UI_block_emboss_set(uiBlock *block, eUIEmbossType emboss)
2.5 More cleanup! - removed old UI font completely, including from uiBeginBlock - emboss hints for uiBlock only have three types now; Regular, Pulldown, or "Nothing" (only icon/text) - removed old font path from Userdef - removed all old button theme hinting - removed old "auto block" to merge buttons in groups (was only in use for radiosity buttons) And went over all warnings. One hooray for make giving clean output :) Well, we need uniform definitions for warnings, so people at least fix them... here's the real bad bugs I found: - in mesh code, a call to editmesh mixed *em and *me - in armature, ED_util.h was not included, so no warnings for wrong call to ED_undo_push() - The extern Py api .h was not included in the bpy_interface.c, showing a several calls using different args. Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
{
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
block->emboss = emboss;
2.5 More cleanup! - removed old UI font completely, including from uiBeginBlock - emboss hints for uiBlock only have three types now; Regular, Pulldown, or "Nothing" (only icon/text) - removed old font path from Userdef - removed all old button theme hinting - removed old "auto block" to merge buttons in groups (was only in use for radiosity buttons) And went over all warnings. One hooray for make giving clean output :) Well, we need uniform definitions for warnings, so people at least fix them... here's the real bad bugs I found: - in mesh code, a call to editmesh mixed *em and *me - in armature, ED_util.h was not included, so no warnings for wrong call to ED_undo_push() - The extern Py api .h was not included in the bpy_interface.c, showing a several calls using different args. Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
}
UI: split theme draw style into separate field Was using UI_BLOCK_LOOP to control draw style, this meant we couldn't use popup theme colors for cases where it the interface has the same purpose as a popup but happens not to use this flag.
2018-09-11 10:56:08 +10:00
void UI_block_theme_style_set(uiBlock *block, char theme_style)
{
block->theme_style = theme_style;
}
UI: Single tab property search This adds a search bar to the properties editor. The full search for every tab isn't included in this patch, but the interaction with panels, searching behavior, UI, region level, and DNA changes are included here. The block-level search works by iterating over the block's button groups and checking whether they match the search. If they do, they are tagged with a flag, and the block's panel is tagged too. For every update (text edit), the panel's expansion is set to whether the panel has a result or not. The search also checks for matching strings inside enums and in panel labels. One complication to this that isn't immediately apparent is that closed panel's subpanels have to be searched too. This adds some complexity to the area-level panel layout code. Possible Future Improvements: - Use the new fuzzy search in BLI - Reset panels to their expansion before the search started if the user escape out of the text box. - Open all child panels of a panel with expansion. Differential Revision: https://developer.blender.org/D8856
2020-09-15 11:25:49 -05:00
bool UI_block_is_search_only(const uiBlock *block)
{
return block->flag & UI_BLOCK_SEARCH_ONLY;
}
void UI_block_set_search_only(uiBlock *block, bool search_only)
{
SET_FLAG_FROM_TEST(block->flag, search_only, UI_BLOCK_SEARCH_ONLY);
}
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
static void ui_but_build_drawstr_float(uiBut *but, double value)
{
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
/* Change negative zero to regular zero, without altering anything else. */
UI: Do Not Display Negative Zero Floats Display negative zero floats as regular zero. Does not alter underlying value. Differential Revision: https://developer.blender.org/D4795 Reviewed by Brecht Van Lommel
2020-08-28 09:30:51 -07:00
value += +0.0f;
Cleanup: replace C-style casts with functional casts for numeric types Use function style casts in C++ headers & source.
2022-09-26 17:38:25 +10:00
if (value == double(FLT_MAX)) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str + "inf";
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
Cleanup: replace C-style casts with functional casts for numeric types Use function style casts in C++ headers & source.
2022-09-26 17:38:25 +10:00
else if (value == double(-FLT_MAX)) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str + "-inf";
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
else if (subtype == PROP_PERCENTAGE) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int prec = ui_but_calc_float_precision(but, value);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{:.{}f}%", but->str, value, prec);
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
else if (subtype == PROP_PIXEL) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int prec = ui_but_calc_float_precision(but, value);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{:.{}f} px", but->str, value, prec);
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
else if (subtype == PROP_FACTOR) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int precision = ui_but_calc_float_precision(but, value);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
if (U.factor_display_type == USER_FACTOR_AS_FACTOR) {
Fix #117423: Broken UI button float display after cleanup Caused by 089c389b5c00ec279429. Previously the draw string was created by appending text inside the buffer multiple times. Now it's formatted in one step. Part of that change was missing for factor display.
2024-01-22 15:46:52 -05:00
but->drawstr = fmt::format("{}{:.{}f}", but->str, value, precision);
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
else {
Fix #117423: Broken UI button float display after cleanup Caused by 089c389b5c00ec279429. Previously the draw string was created by appending text inside the buffer multiple times. Now it's formatted in one step. Part of that change was missing for factor display.
2024-01-22 15:46:52 -05:00
but->drawstr = fmt::format("{}{:.{}f}", but->str, value * 100, std::max(0, precision - 2));
UI: New option to display factors as percentages The option can be changed in the Preferences in `Interface -> Editors -> Factor Display Type`. Reviewers: campbellbarton, brecht, billreynish Differential Revision: https://developer.blender.org/D4462
2019-03-13 16:58:00 +01:00
}
}
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
else if (ui_but_is_unit(but)) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
char new_str[UI_MAX_DRAW_STR];
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
ui_get_but_string_unit(but, new_str, sizeof(new_str), value, true, -1);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str + new_str;
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
else {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int prec = ui_but_calc_float_precision(but, value);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{:.{}f}", but->str, value, prec);
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
}
static void ui_but_build_drawstr_int(uiBut *but, int value)
{
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str + std::to_string(value);
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
if (subtype == PROP_PERCENTAGE) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr += "%";
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
else if (subtype == PROP_PIXEL) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr += " px";
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
}
}
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
/**
* \param but: Button to update.
* \param validate: When set, this function may change the button value.
* Otherwise treat the button value as read-only.
*/
Fix T62120: number button editing outside of soft max range jumps.
2019-03-14 18:27:17 +01:00
static void ui_but_update_ex(uiBut *but, const bool validate)
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
{
/* if something changed in the button */
style cleanup: interface
2012-03-30 01:51:25 +00:00
double value = UI_BUT_VALUE_UNSET;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_select_flag(but, &value);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix #21122: color sliders behaving weirdly.
2010-03-12 14:18:14 +00:00
/* only update soft range while not editing */
Fix T62120: number button editing outside of soft max range jumps.
2019-03-14 18:27:17 +01:00
if (!ui_but_is_editing(but)) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if ((but->rnaprop != nullptr) || (but->poin && (but->pointype & UI_BUT_POIN_TYPES))) {
UI: fix buttons ranges not properly updated when tabbing to next/previous button This was reported for the FCurve modifier restrict ranges, but might fail elsewhere, too. Reason is that the post_but has its range (hardmin/ hardmax etc) set before the updates to the active button take place, so changes here dont end up on the post_but (even though the RNA range function is properly called for a new defined button - new one is not the same as the post_but though). Now update the ranges on the post_but when that gets active. Fixes T78763 Maniphest Tasks: T78763 Differential Revision: https://developer.blender.org/D8265
2020-07-09 15:38:31 +02:00
ui_but_range_set_soft(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
fix [#36008] Can't set values higher than 1.0 in HSV colour picker (But can in RGB) - also some strange behavior
2013-07-09 04:00:56 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* test for min and max, icon sliders, etc */
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (but->type) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_NUM:
case UI_BTYPE_SCROLL:
case UI_BTYPE_NUM_SLIDER:
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
if (validate) {
UI_GET_BUT_VALUE_INIT(but, value);
Cleanup: replace C-style casts with functional casts for numeric types Some changes missed from f68cfd6bb078482c4a779a6e26a56e2734edb5b8.
2022-09-25 20:27:46 +10:00
if (value < double(but->hardmin)) {
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
ui_but_value_set(but, but->hardmin);
}
Cleanup: replace C-style casts with functional casts for numeric types Some changes missed from f68cfd6bb078482c4a779a6e26a56e2734edb5b8.
2022-09-25 20:27:46 +10:00
else if (value > double(but->hardmax)) {
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
ui_but_value_set(but, but->hardmax);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
/* max must never be smaller than min! Both being equal is allowed though */
BLI_assert(but->softmin <= but->softmax && but->hardmin <= but->hardmax);
}
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
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Correction to previous commit Just realized menu buttons are using hardmin and hardmax for a bad hack which will make the assert fail :/
2015-01-06 00:02:57 +01:00
case UI_BTYPE_ICON_TOGGLE:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_ICON_TOGGLE_N:
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if ((but->rnaprop == nullptr) || (RNA_property_flag(but->rnaprop) & PROP_ICONS_CONSECUTIVE))
{
UI: allow off/on icons to be in reverse order. The same icons are reused for "hide" and "show" properties, which need to be in reverse order compared to each other.
2018-10-29 16:58:34 +01:00
if (but->rnaprop && RNA_property_flag(but->rnaprop) & PROP_ICONS_REVERSE) {
but->drawflag |= UI_BUT_ICON_REVERSE;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: comments and unused code
2018-10-25 13:41:32 +00:00
but->iconadd = (but->flag & UI_SELECT) ? 1 : 0;
UI * Added option for panel to be closed by default. * Added support for RNA property and enum icons in buttons. * Remove some deprecated RNA menu code. * Fix issue with newly created panels not being inserted in the right place. * Fix issue with 3-split layout not being divided correctly. * FIx issue with menu items not drawing correct using python UI.
2009-06-16 01:08:39 +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
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use an enum typedef for button types. it was quite annoying debugging UI code since the defines are bit-shifted. GDB would show but->type as 13824 and blender define was (27 << 9). Now but->type shows as a humanly readable names.
2012-09-10 06:05:19 +00:00
/* quiet warnings for unhandled types */
default:
break;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (but->type) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_MENU:
UI: fix assert Replace hard-coded button size check with UI_UNIT_X. Caused icon-only buttons to have strings assigned based on UI-scale.
2018-05-25 10:45:48 +02:00
if (BLI_rctf_size_x(&but->rect) >= (UI_UNIT_X * 2)) {
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +11:00
/* only needed for menus in popup blocks that don't recreate buttons on redraw */
if (but->block->flag & UI_BLOCK_LOOP) {
if (but->rnaprop && (RNA_property_type(but->rnaprop) == PROP_ENUM)) {
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int value_enum = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix T47780: Icons don't update in floating panels
2016-03-15 21:12:37 +11:00
EnumPropertyItem item;
if (RNA_property_enum_item_from_value_gettexted(
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
static_cast<bContext *>(but->block->evil_C),
&but->rnapoin,
but->rnaprop,
value_enum,
&item))
{
Cleanup: UI: Remove unnecessary function for setting button string
2024-01-31 13:42:57 -05:00
but->str = item.name;
Refactor: Solve invalid icon-id enum values, use type alias Some code attempted to use `BIFIconID` instead of `int` to pass around icon-ids. Problem is, that this is just a subset of the allowed ids, more icons may be created at runtime and extend the range of valid icon-ids. Such icons could give runtime warning prints. Idea is to use a `using BIFIconID = int;` instead. This way there is still a descriptive type name, while the whole dynamic range of possible icon-ids is supported. Additionally multiple `using BIFIconID = int;` declarations are valid, so we can place these in multiple headers and use the type name in APIs instead of just `int`, whithout having to include a single header defining them. A type mismatch (one instance differs from the others) will result in a compiler error. Pull Request: https://projects.blender.org/blender/blender/pulls/111052
2023-08-14 12:06:35 +02:00
but->icon = item.icon;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +11:00
}
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str;
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +11:00
}
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_NUM:
case UI_BTYPE_NUM_SLIDER:
Refactor building the draw string for floats and ints Differential Revision: https://developer.blender.org/D4466
2019-03-07 12:01:32 +01:00
if (but->editstr) {
break;
}
UI_GET_BUT_VALUE_INIT(but, value);
if (ui_but_is_float(but)) {
ui_but_build_drawstr_float(but, value);
}
else {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
ui_but_build_drawstr_int(but, int(value));
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_LABEL:
if (ui_but_is_float(but)) {
code cleanup: defines with braces - end with '(void)0' so callers must end with ';' like normal function. ... without this some editors dont parse the source so well.
2012-05-27 12:21:13 +00:00
UI_GET_BUT_VALUE_INIT(but, value);
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int prec = ui_but_calc_float_precision(but, value);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{:.{}f}", but->str, value, prec);
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
else {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str;
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_TEXT:
case UI_BTYPE_SEARCH_MENU:
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (!but->editstr) {
char str[UI_MAX_DRAW_STR];
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_string_get(but, str, UI_MAX_DRAW_STR);
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{}", but->str, str);
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_KEY_EVENT: {
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
const char *str;
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->flag & UI_SELECT) {
I18n: disambiguate messages - "Lines" in the sense of number of lines - "Number" can mean "amount, count" or "index, offset" - "Second" can be an ordinal number or a unit - "Root": add the brush curve to the "square root falloff" sense - "Strip" can be a sequence or a type of hair rendering - "Constant" in the sense of a value, for the Geometry Nodes add submenu (#105447). Additionally, extract: - "Press a key" from the Keymap preferences. - "MaskLayer", upon new mask layer creation Ref #43295, #105447
2023-03-03 14:44:21 +01:00
str = IFACE_("Press a key");
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
else {
code cleanup: defines with braces - end with '(void)0' so callers must end with ';' like normal function. ... without this some editors dont parse the source so well.
2012-05-27 12:21:13 +00:00
UI_GET_BUT_VALUE_INIT(but, value);
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
str = WM_key_event_string(short(value), false);
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = fmt::format("{}{}", but->str, str);
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_HOTKEY_EVENT:
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->flag & UI_SELECT) {
UI Code Quality: Use derived struct for hot-key buttons `uiBut` contained a variable that was only used for these hot-key buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag, which is also only used for this button type. We are running out of available bits for flags, so this would be useful. Continuing the work from 49f088e2d093. Part of T74432.
2022-05-12 17:30:18 +02:00
const uiButHotkeyEvent *hotkey_but = (uiButHotkeyEvent *)but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Use derived struct for hot-key buttons `uiBut` contained a variable that was only used for these hot-key buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag, which is also only used for this button type. We are running out of available bits for flags, so this would be useful. Continuing the work from 49f088e2d093. Part of T74432.
2022-05-12 17:30:18 +02:00
if (hotkey_but->modifier_key) {
UI: resolve inconsistency with modifier labels while assigning shortcuts Reuse WM_keymap_item_to_string to ensure labels match (would show Cmd on Linux, then refresh to OS once set).
2023-06-23 10:08:58 +10:00
/* Rely on #KM_NOTHING being zero for `type`, `val` ... etc. */
wmKeyMapItem kmi_dummy = {nullptr};
kmi_dummy.shift = (hotkey_but->modifier_key & KM_SHIFT) ? KM_PRESS : KM_NOTHING;
kmi_dummy.ctrl = (hotkey_but->modifier_key & KM_CTRL) ? KM_PRESS : KM_NOTHING;
kmi_dummy.alt = (hotkey_but->modifier_key & KM_ALT) ? KM_PRESS : KM_NOTHING;
kmi_dummy.oskey = (hotkey_but->modifier_key & KM_OSKEY) ? KM_PRESS : KM_NOTHING;
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
but->drawstr = WM_keymap_item_to_string(&kmi_dummy, true).value_or("");
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
else {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = IFACE_("Press a key");
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
}
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
else {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
case UI_BTYPE_HSVCUBE:
case UI_BTYPE_HSVCIRCLE:
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
default:
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr = but->str;
code cleanup: add break statements in switch ()'s, (even at the last case).
2013-07-21 08:16:37 +00:00
break;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
/* if we are doing text editing, this will override the drawstr */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (but->editstr) {
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
but->drawstr.clear();
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
/* text clipping moved to widget drawing code itself */
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
}
Fix button display clamping values Displaying a button would clamp the value if the button was outside the range. This could be OK in some cases, however it's problematic with object dimensions which would re-scale objects on showing the panel. Add `ui_but_update_edited` when its OK to modify the value.
2016-02-23 09:55:16 +11:00
void ui_but_update(uiBut *but)
{
ui_but_update_ex(but, false);
}
void ui_but_update_edited(uiBut *but)
{
ui_but_update_ex(but, true);
}
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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_align_begin(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
{
/* if other align was active, end it */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block->flag & UI_BUT_ALIGN) {
UI_block_align_end(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
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
block->flag |= UI_BUT_ALIGN_DOWN;
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
block->alignnr++;
Cleanup: comments in code
2023-02-06 12:23:01 +11:00
/* Buttons declared after this call will get this `alignnr`. */ /* XXX flag? */
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_align_end(uiBlock *block)
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
{
style cleanup
2012-08-19 10:41:27 +00:00
block->flag &= ~UI_BUT_ALIGN; /* all 4 flags */
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
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
ColorManagedDisplay *ui_block_cm_display_get(uiBlock *block)
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
{
return IMB_colormanagement_display_get_named(block->display_device);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void ui_block_cm_to_display_space_v3(uiBlock *block, float pixel[3])
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
{
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
ColorManagedDisplay *display = ui_block_cm_display_get(block);
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
IMB_colormanagement_scene_linear_to_display_v3(pixel, display);
}
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
/**
* Factory function: Allocate button and set #uiBut.type.
*/
static uiBut *ui_but_new(const eButType type)
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
{
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
uiBut *but = nullptr;
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
switch (type) {
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
case UI_BTYPE_NUM:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButNumber>("uiButNumber");
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
break;
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
case UI_BTYPE_NUM_SLIDER:
but = MEM_new<uiButNumberSlider>("uiButNumber");
break;
UI Code Quality: Use derived struct for color buttons For the main rationale behind this design, see 03b122e2a18df. Further, this removes users of `uiBut.a1`/`uiBut.a2`, which is a very ugly design choice (hard to reason about). Part of Part of T74432.
2020-08-07 15:02:07 +02:00
case UI_BTYPE_COLOR:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButColor>("uiButColor");
UI Code Quality: Use derived struct for color buttons For the main rationale behind this design, see 03b122e2a18df. Further, this removes users of `uiBut.a1`/`uiBut.a2`, which is a very ugly design choice (hard to reason about). Part of Part of T74432.
2020-08-07 15:02:07 +02:00
break;
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
case UI_BTYPE_DECORATOR:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButDecorator>("uiButDecorator");
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
break;
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
case UI_BTYPE_TAB:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButTab>("uiButTab");
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
break;
case UI_BTYPE_SEARCH_MENU:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButSearch>("uiButSearch");
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
break;
Cleanup: rename uiButProgressbar to uiButProgress Prepare for other types of progress to be added.
2023-07-12 13:15:39 +10:00
case UI_BTYPE_PROGRESS:
but = MEM_new<uiButProgress>("uiButProgress");
UI Code Quality: Use derived struct for progessbar buttons For the main rationale behind this design, see 03b122e2a18df. Further, this removes users of `uiBut.a1`, which is a very ugly design choice (hard to reason about). Part of T74432.
2020-08-07 15:16:26 +02:00
break;
Refactor: UI_BTYPE_SEPR_LINE Without Need for uiBut->a1 The line separator needs to know vertical or horizontal orientation at draw time, and is independent of button rect. This PR removes the use of uiBut->a1 for this in favor of a derived struct. Pull Request: https://projects.blender.org/blender/blender/pulls/118969
2024-03-01 18:09:02 +01:00
case UI_BTYPE_SEPR_LINE:
but = MEM_new<uiButSeparatorLine>("uiButSeparatorLine");
break;
UI Code Quality: Use derived struct for HSV Cube buttons For the main rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1, which is a very ugly design choice (hard to reason about). Part of T74432.
2020-08-07 17:42:13 +02:00
case UI_BTYPE_HSVCUBE:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButHSVCube>("uiButHSVCube");
UI Code Quality: Use derived struct for HSV Cube buttons For the main rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1, which is a very ugly design choice (hard to reason about). Part of T74432.
2020-08-07 17:42:13 +02:00
break;
UI Code Quality: Use derived struct for color ramp buttons The same changes as rB570044e9f412 and rB0ab21bf06ae0.
2020-08-13 22:00:50 -04:00
case UI_BTYPE_COLORBAND:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButColorBand>("uiButColorBand");
UI Code Quality: Use derived struct for color ramp buttons The same changes as rB570044e9f412 and rB0ab21bf06ae0.
2020-08-13 22:00:50 -04:00
break;
UI Code Quality: Use derived struct for curve mapping buttons The same changes as in rB570044e9f412.
2020-08-13 21:33:47 -04:00
case UI_BTYPE_CURVE:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButCurveMapping>("uiButCurveMapping");
UI Code Quality: Use derived struct for curve mapping buttons The same changes as in rB570044e9f412.
2020-08-13 21:33:47 -04:00
break;
UI Code Quality: Use derived struct for curve profile buttons Continuing the work from rB49f088e2d093. Differential Revision: https://developer.blender.org/D8561
2020-08-13 21:00:54 -04:00
case UI_BTYPE_CURVEPROFILE:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButCurveProfile>("uiButCurveProfile");
UI Code Quality: Use derived struct for curve profile buttons Continuing the work from rB49f088e2d093. Differential Revision: https://developer.blender.org/D8561
2020-08-13 21:00:54 -04:00
break;
UI Code Quality: Use derived struct for hot-key buttons `uiBut` contained a variable that was only used for these hot-key buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag, which is also only used for this button type. We are running out of available bits for flags, so this would be useful. Continuing the work from 49f088e2d093. Part of T74432.
2022-05-12 17:30:18 +02:00
case UI_BTYPE_HOTKEY_EVENT:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButHotkeyEvent>("uiButHotkeyEvent");
UI Code Quality: Use derived struct for hot-key buttons `uiBut` contained a variable that was only used for these hot-key buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag, which is also only used for this button type. We are running out of available bits for flags, so this would be useful. Continuing the work from 49f088e2d093. Part of T74432.
2022-05-12 17:30:18 +02:00
break;
UI: Port view item features to base class, merge view item button types No user visible changes expected. Merges the tree row and grid tile button types, which were mostly doing the same things. The idea is that there is a button type for highlighting, as well as supporting general view item features (e.g. renaming, drag/drop, etc.). So instead there is a view item button type now. Also ports view item features like renaming, custom context menus, drag controllers and drop controllers to `ui::AbstractViewItem` (the new base class for all view items). This should be quite an improvement because: - Merges code that was duplicated over view items. - Mentioned features (renaming, drag & drop, ...) are much easier to implement in new view types now. Most of it comes "for free". - Further features will immediately become availalbe to all views (e.g. selection). - Simplifies APIs, there don't have to be functions for individual view item types anymore. - View item classes are split and thus less overwhelming visually. - View item buttons now share all code (drawing, handling, etc.) - We're soon running out of available button types, this commit merges two into one. I was hoping I could do this in multiple smaller commits, but things were quite intertwined so that would've taken quite some effort.
2022-07-19 16:14:42 +02:00
case UI_BTYPE_VIEW_ITEM:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiButViewItem>("uiButViewItem");
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
break;
Cleanup: UI: Use derived struct for label buttons, remove a1, a2 usage
2024-03-01 13:46:06 -05:00
case UI_BTYPE_LABEL:
but = MEM_new<uiButLabel>("uiButLabel");
break;
Cleanup: UI: Use derived struct for list scroll bars, remove a1, a2 usage
2024-03-01 13:59:03 -05:00
case UI_BTYPE_SCROLL:
but = MEM_new<uiButScrollBar>("uiButScrollBar");
break;
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
default:
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but = MEM_new<uiBut>("uiBut");
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
break;
}
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
but->type = type;
return but;
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
}
uiBut *ui_but_change_type(uiBut *but, eButType new_type)
{
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
if (but->type == new_type) {
/* Nothing to do. */
return but;
}
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
uiBut *insert_after_but = but->prev;
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
/* Remove old button address */
BLI_remlink(&but->block->buttons, but);
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
const uiBut *old_but_ptr = but;
/* Button may have pointer to a member within itself, this will have to be updated. */
const bool has_poin_ptr_to_self = but->poin == (char *)but;
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
/* Copy construct button with the new type. */
but = ui_but_new(new_type);
*but = *old_but_ptr;
Fix number sliders not working Own mistake in d204830107ef. For some buttons the type is changed after construction, which means the button has to be reconstructed. For example number buttons can be turned into number slider buttons this way. New code was unintentionally overriding the button type after reconstruction with the old type again.
2023-02-03 18:42:14 +01:00
/* We didn't mean to override this :) */
but->type = new_type;
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
if (has_poin_ptr_to_self) {
but->poin = (char *)but;
}
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
BLI_insertlinkafter(&but->block->buttons, insert_after_but, but);
Cleanup (UI): Early-exit rather than having a big-ish conditional body It's generally considered a better codestyle to check conditions early and exit early when they are not met, over having most logic of a function within a big `if`-block. Otherwise people have to go over the entire block to see if there's possibly an `else` somewhere, or any followup logic.
2020-09-21 15:03:02 +02:00
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
if (but->layout) {
const bool found_layout = ui_layout_replace_but_ptr(but->layout, old_but_ptr, but);
BLI_assert(found_layout);
UNUSED_VARS_NDEBUG(found_layout);
ui_button_group_replace_but_ptr(uiLayoutGetBlock(but->layout), old_but_ptr, but);
}
UI: building without Python again Also quiet some warnings.
2021-08-03 22:45:37 +10:00
#ifdef WITH_PYTHON
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
if (UI_editsource_enable_check()) {
UI_editsource_but_replace(old_but_ptr, but);
UI: New Global Top-Bar (WIP) == Main Features/Changes for Users * Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars. * Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector. * Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here. * Individual sections of the topbar are individually scrollable. * Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting. * Top-bar should scale nicely with DPI. * The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes). * Info editors at the top of the window and using the full window width with be replaced by the top-bar. * In fullscreen modes, no more info editor is added on top, the top-bar replaces it. == Technical Features/Changes * Adds initial support for global areas A global area is part of the window, not part of the regular screen-layout. I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas. * Adds a TOPBAR editor type The editor type is hidden in the UI editor type menu. * Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY) * Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar. * Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds. The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved. * Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code. Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being. NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility. == ToDo's It's a bit hard to predict all the ToDo's here are the known main ones: * Add options for the new active-tool system and for operator redo to the topbar. * Automatically hide the top-bar in fullscreen modes. * General visual polish. * Top-bar drag & drop support (WIP in temp-tab_drag_drop). * Improve dynamic regions (should also fix some layout glitches). * Make internal terminology consistent. * Enable topbar file writing once design is more advanced. * Address TODO's and XXX's in code :) Thanks @brecht for the review! And @sergey for the complaining ;) Differential Revision: D2758
2018-04-20 17:14:03 +02:00
}
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
#endif
MEM_delete(old_but_ptr);
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
return but;
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
}
style cleanup - use aligned * prefixed blocks for descriptive comments (was already used a lot and part of proposed style guide).
2012-03-03 16:31:46 +00:00
/**
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* \param x, y: The lower left hand corner of the button (X axis)
* \param width, height: The size of the button.
correct indentation and some whitespace edits (no functional changes)
2011-11-11 13:09:14 +00:00
*/
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
static uiBut *ui_def_but(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Optional Complex Layout for Workspace Status Optionally allow complex layout instead of just plain text when using ED_workspace_status_text. Pull Request: https://projects.blender.org/blender/blender/pulls/120595
2024-05-06 23:52:37 +02:00
/* Allow negative separators. */
Cleanup: quiet parentheses warning
2024-05-07 12:59:12 +10:00
BLI_assert((width >= 0 && height >= 0) || (type == UI_BTYPE_SEPR));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: correct misleading use of LABEL button type.
2012-09-14 05:44:47 +00:00
if (type & UI_BUT_POIN_TYPES) { /* a pointer is required */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (poin == nullptr) {
code cleanup: correct misleading use of LABEL button type.
2012-09-14 05:44:47 +00:00
BLI_assert(0);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
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
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
uiBut *but = ui_but_new((eButType)(type & BUTTYPE));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
but->pointype = (eButPointerType)(type & UI_BUT_POIN_TYPES);
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
but->bit = type & UI_BUT_POIN_BIT;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->bitnr = type & 31;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->retval = retval;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI: Remove unnecessary function for setting button string
2024-01-31 13:42:57 -05:00
but->str = str;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but->rect.xmin = x;
but->rect.ymin = y;
but->rect.xmax = but->rect.xmin + width;
but->rect.ymax = but->rect.ymin + height;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
but->poin = (char *)poin;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->hardmin = but->softmin = min;
but->hardmax = but->softmax = max;
but->tip = tip;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Various cleanups related to button locking * Rename uiBut.lockstr to disabled_info * Remove unreachable code * Replace duplicated check with assert * Replace overly ambitious check with assert * Add comments
2016-09-19 02:25:59 +02:00
but->disabled_info = block->lockstr;
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
but->emboss = block->emboss;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: correct spelling in comments
2021-02-05 16:23:34 +11:00
but->block = block; /* pointer back, used for front-buffer status, and picker. */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if ((block->flag & UI_BUT_ALIGN) && ui_but_can_align(but)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->alignnr = block->alignnr;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func = block->func;
but->func_arg1 = block->func_arg1;
but->func_arg2 = block->func_arg2;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->funcN = block->funcN;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block->func_argN) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func_argN = MEM_dupallocN(block->func_argN);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->pos = -1; /* cursor invisible */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ELEM(but->type, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER)) { /* add a space to name */
Cleanup: UI: Remove unnecessary function for setting button string
2024-01-31 13:42:57 -05:00
if (!but->str.empty() && but->str.size() < UI_MAX_NAME_STR - 2) {
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
if (but->str[but->str.size() - 1] != ' ') {
but->str += ' ';
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
if (block->flag & UI_BLOCK_RADIAL) {
Fix: Icon alignment for scaled pie buttons with no text
2017-06-20 20:15:04 +03:00
but->drawflag |= UI_BUT_TEXT_LEFT;
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
if (!but->str.empty()) {
Fix: Icon alignment for scaled pie buttons with no text
2017-06-20 20:15:04 +03:00
but->drawflag |= UI_BUT_ICON_LEFT;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Fix T56898: misaligned icons in buttons in popovers.
2018-10-11 17:42:50 +02:00
}
UI: Correct the text alignment in the quick setup (splash screen) dialog The "quick setup" dialog is actually a 'menu', and the "splash screen" block contains the UI_BLOCK_LOOP flag which causes the buttons' text to align to the left, however, usually regular buttons have centered text. As a workaround, add the UI_BLOCK_QUICK_SETUP flag which prevents the text from being left-aligned. Differential Revision: https://developer.blender.org/D10486 Reviewed by: Julian Eisel
2021-02-21 17:26:55 +01:00
else if (((block->flag & UI_BLOCK_LOOP) && !ui_block_is_popover(block) &&
!(block->flag & UI_BLOCK_QUICK_SETUP)) ||
UI: Cleanup (line length)
2014-11-11 16:52:03 +01:00
ELEM(but->type,
UI_BTYPE_MENU,
UI_BTYPE_TEXT,
UI_BTYPE_LABEL,
UI_BTYPE_BLOCK,
UI_BTYPE_BUT_MENU,
UI_BTYPE_SEARCH_MENU,
UI: experiment to make popover buttons draw like enum menus. Looks better for 3D viewport shading, but needs more tweaks to distinguish it from other button types probably.
2018-05-05 14:47:50 +02:00
UI_BTYPE_POPOVER))
{
Fix misaligned icon in search buttons after recent changes.
2018-10-12 15:55:36 +02:00
but->drawflag |= (UI_BUT_TEXT_LEFT | UI_BUT_ICON_LEFT);
style cleanup
2012-07-21 16:21:42 +00:00
}
User Interface: Align number buttons labels to the left, number right
2013-12-11 21:27:13 +11:00
#ifdef USE_NUMBUTS_LR_ALIGN
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
else if (ELEM(but->type, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER)) {
Cleanup: UI: Remove unnecessary function for setting button string
2024-01-31 13:42:57 -05:00
if (!but->str.empty()) {
UI: center align number buttons w/o text This makes supporting split properties and text possible, see T54951
2018-05-27 21:06:38 +02:00
but->drawflag |= UI_BUT_TEXT_LEFT;
}
User Interface: Align number buttons labels to the left, number right
2013-12-11 21:27:13 +11:00
}
#endif
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
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= (block->flag & UI_BUT_ALIGN);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Completely replace/remove uiBut.lock Old leftover from pre 2.5 days. Now handled through UI_BUT_DISABLED button flag.
2016-09-19 01:49:17 +02:00
if (block->lock == true) {
but->flag |= UI_BUT_DISABLED;
* Enabled disabled drawing for 'locked' buttons (made with uiBlockSetButLock())
2009-01-04 07:50:41 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
/* keep track of UI_interface.hh */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ELEM(but->type,
UI_BTYPE_BLOCK,
UI_BTYPE_BUT,
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
UI_BTYPE_DECORATOR,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_BTYPE_LABEL,
UI_BTYPE_PULLDOWN,
UI_BTYPE_ROUNDBOX,
UI_BTYPE_LISTBOX,
UI_BTYPE_BUT_MENU,
UI_BTYPE_SCROLL,
UI_BTYPE_GRIP,
UI: Separator spacer This support layout.separator_spacer() to be used by headers as a way to dynamically separate the ui buttons. Right now no UI file is changed, though we can use this right away in the timeline, and shortly after in the viewport header (moving settings from the topbar to it). Original design by William Reynish. Review: Campbell Barton D3468
2018-06-11 14:33:53 +02:00
UI_BTYPE_SEPR,
UI_BTYPE_SEPR_LINE,
UI_BTYPE_SEPR_SPACER) ||
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
(but->type >= UI_BTYPE_SEARCH_MENU))
{
/* pass */
}
else {
but->flag |= UI_BUT_UNDO;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
if (ELEM(but->type, UI_BTYPE_COLOR)) {
but->dragflag |= UI_BUT_DRAG_FULL_BUT;
}
2.5 UI: Modifier Template * template_modifier creates the modifier box, and returns a layout to put the buttons in. * Only the armature modifier is now done with python code, all other modifiers use C code. To convert a modifier to python, remove the corresponding C code and create a function in DATA_PT_modifiers. * Some modifiers still require some RNA work to get it working well, especially to make pointers editable. Mostly that is a matter of defining an own _set callback and put some of the modifier C code into it. * Still various buttons that don't work, like for hooks or mesh deform binding. * Fix for crashing decimate modifier (still disabled). * Removed UI_BUT_NO_HILITE, HMENU. * Make uiLayoutBox work with align.
2009-05-21 15:34:09 +00:00
BLI_addtail(&block->buttons, but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block->curlayout) {
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
ui_layout_add_but(block->curlayout, but);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
UI: * Template slots are no longer specified per item, but are a state now, set with uiTemplateSlot. * Some renaming of Layout functions for consistency. * Fix for roundbox in stack template, now is always behind the other buttons. * Improved python API for layout: http://www.pasteall.org/5008/python
2009-04-11 01:52:27 +00:00
compile without python works again
2011-11-03 23:20:54 +00:00
#ifdef WITH_PYTHON
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
/* If the 'UI_OT_editsource' is running, extract the source info from the button. */
Context menu 'Edit Source' operator no longer needs to be enabled as a build option, improved this so the python file:line lookups are only done when the operator runs (previously this was done for every button, every draw when the build option was enabled). Perhaps this should be hidden when not running with --debug, easy to change.
2011-10-23 04:13:56 +00:00
if (UI_editsource_enable_check()) {
UI_editsource_active_but_test(but);
debug build option WITH_PYTHON_UI_INFO, so you can right click and edit the python source for UI layout directly.
2011-10-20 00:48:00 +00:00
}
compile without python works again
2011-11-03 23:20:54 +00:00
#endif
debug build option WITH_PYTHON_UI_INFO, so you can right click and edit the python source for UI layout directly.
2011-10-20 00:48:00 +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
return but;
}
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
void ui_def_but_icon(uiBut *but, const int icon, const int flag)
Cleanup: style
2015-05-13 06:10:49 +10:00
{
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
if (icon) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
ui_icon_ensure_deferred(static_cast<const bContext *>(but->block->evil_C),
icon,
(flag & UI_BUT_ICON_PREVIEW) != 0);
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
}
Refactor: Solve invalid icon-id enum values, use type alias Some code attempted to use `BIFIconID` instead of `int` to pass around icon-ids. Problem is, that this is just a subset of the allowed ids, more icons may be created at runtime and extend the range of valid icon-ids. Such icons could give runtime warning prints. Idea is to use a `using BIFIconID = int;` instead. This way there is still a descriptive type name, while the whole dynamic range of possible icon-ids is supported. Additionally multiple `using BIFIconID = int;` declarations are valid, so we can place these in multiple headers and use the type name in APIs instead of just `int`, whithout having to include a single header defining them. A type mismatch (one instance differs from the others) will result in a compiler error. Pull Request: https://projects.blender.org/blender/blender/pulls/111052
2023-08-14 12:06:35 +02:00
but->icon = icon;
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
but->flag |= flag;
Cleanup: Use std::string to store UI button string This simplifies memory management and button string manipulation in general. Just change one of the few strings stored in `uiBut` for now. Pull Request: https://projects.blender.org/blender/blender/pulls/117183
2024-01-16 21:04:17 +01:00
if (!but->str.empty()) {
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
but->drawflag |= UI_BUT_ICON_LEFT;
}
}
UI: support drawing booleans with icons as check-boxes Previously, if a boolean happened to use an icon there was no way to make it display as a check-box from Python scripts. The previous logic meant we ended up having to edit the RNA. Since booleans with icons don't work well with the split-property layout (now used for most of the interface). Icons were being removed from RNA then added back using awkward Python ternary expressions in the interface scripts. The toggle argument now has an unset state (-1). - toggle=True: no checkbox (emboss). - toggle=False: always use a checkbox (no icon). - toggle=(unset/-1): depends on the icon status, default as before. Since toggle=False was default, this isn't used in existing UI logic.
2019-05-21 14:39:09 +10:00
void ui_def_but_icon_clear(uiBut *but)
{
but->icon = ICON_NONE;
but->flag &= ~UI_HAS_ICON;
but->drawflag &= ~UI_BUT_ICON_LEFT;
}
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
static void ui_def_but_rna__menu(bContext *C, uiLayout *layout, void *but_p)
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
{
uiBlock *block = uiLayoutGetBlock(layout);
uiPopupBlockHandle *handle = block->handle;
uiBut *but = (uiBut *)but_p;
UI: Highlight Selected Enum Highlight the currently-selected item in enum, and some other, lists. Pull Request: https://projects.blender.org/blender/blender/pulls/111074
2023-09-01 21:33:03 +02:00
const int current_value = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
/* see comment in ui_item_enum_expand, re: `uiname`. */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
const EnumPropertyItem *item_array;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_flag_enable(block, UI_BLOCK_MOVEMOUSE_QUIT);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
bool free;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_enum_items_gettexted(static_cast<bContext *>(block->evil_C),
&but->rnapoin,
but->rnaprop,
&item_array,
nullptr,
&free);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: spelling
2021-03-18 09:35:12 +11:00
/* We don't want nested rows, cols in menus. */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_layout_set_current(block, layout);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int totitems = 0;
UI: Simplified Categorized Menus Menus with categories gain a dividing line and omit the title. Differential Revision: https://developer.blender.org/D5135 Reviewed by Brecht Van Lommel
2020-10-19 11:28:38 -07:00
int categories = 0;
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
bool has_item_with_icon = false;
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
int columns = 1;
int rows = 0;
const wmWindow *win = CTX_wm_window(C);
const int row_height = int(float(UI_UNIT_Y) / but->block->aspect);
/* Calculate max_rows from how many rows can fit in this window. */
const int max_rows = (win->sizey - (4 * row_height)) / row_height;
float text_width = 0.0f;
BLF_size(BLF_default(), UI_style_get()->widgetlabel.points * UI_SCALE_FAC);
int col_rows = 0;
float col_width = 0.0f;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
for (const EnumPropertyItem *item = item_array; item->identifier; item++, totitems++) {
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
col_rows++;
if (col_rows > 1 && (col_rows > max_rows || (!item->identifier[0] && item->name))) {
columns++;
text_width += col_width;
col_width = 0;
col_rows = 0;
}
if (!item->identifier[0] && item->name) {
categories++;
Fix #115815: Include Category name in Enum Row Calculation Report #115815 shows a time where our calculation of rows and columns should also include the category name lines. The code was calculating where to break not including these and is too short if it has a category. Pull Request: https://projects.blender.org/blender/blender/pulls/115822
2023-12-06 01:37:04 +01:00
/* The category name adds to the column length. */
col_rows++;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
if (item->icon) {
has_item_with_icon = true;
}
Fix #115023: Error Measuring Null Menu Item Name Do not attempt to measure the length of a null string. Pull Request: https://projects.blender.org/blender/blender/pulls/115027
2023-11-17 06:00:28 +01:00
if (item->name && item->name[0]) {
float item_width = BLF_width(BLF_default(), item->name, BLF_DRAW_STR_DUMMY_MAX);
Cleanup: replace MAX2 with std::max
2023-11-29 17:11:09 +11:00
col_width = std::max(col_width, item_width + (100.0f * UI_SCALE_FAC));
Fix #115023: Error Measuring Null Menu Item Name Do not attempt to measure the length of a null string. Pull Request: https://projects.blender.org/blender/blender/pulls/115027
2023-11-17 06:00:28 +01:00
}
Cleanup: replace MAX2 with std::max
2023-11-29 17:11:09 +11:00
rows = std::max(rows, col_rows);
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
}
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
text_width += col_width;
text_width /= but->block->aspect;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix #115275: Allow Wrapping of Single Column Enum Menus Enum menus that do not have categories should be able to wrap to multiple columns is there is enough horizontal space. Pull Request: https://projects.blender.org/blender/blender/pulls/115283
2023-11-22 21:15:00 +01:00
/* Wrap long single-column lists. */
if (categories == 0) {
Cleanup: various C++ updates from C
2023-11-27 10:55:40 +11:00
columns = std::max((totitems + 20) / 20, 1);
Fix #115275: Allow Wrapping of Single Column Enum Menus Enum menus that do not have categories should be able to wrap to multiple columns is there is enough horizontal space. Pull Request: https://projects.blender.org/blender/blender/pulls/115283
2023-11-22 21:15:00 +01:00
if (columns > 8) {
columns = (totitems + 25) / 25;
}
Cleanup: replace MAX2 with std::max
2023-11-29 17:11:09 +11:00
rows = std::max(totitems / columns, 1);
Fix #115275: Allow Wrapping of Single Column Enum Menus Enum menus that do not have categories should be able to wrap to multiple columns is there is enough horizontal space. Pull Request: https://projects.blender.org/blender/blender/pulls/115283
2023-11-22 21:15:00 +01:00
while (rows * columns < totitems) {
rows++;
}
}
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
/* If the estimated width is greater than available size, collapse to one column. */
Fix #116471: some menus incorrectly display vertical on macOS Take into account retina pixel size for estimating window width when checking if the menu fits.
2023-12-22 18:23:32 +01:00
if (columns > 1 && text_width > WM_window_pixels_x(win)) {
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
columns = 1;
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
rows = totitems;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Simplified Categorized Menus Menus with categories gain a dividing line and omit the title. Differential Revision: https://developer.blender.org/D5135 Reviewed by Brecht Van Lommel
2020-10-19 11:28:38 -07:00
const char *title = RNA_property_ui_name(but->rnaprop);
UI: Improved Enum Title Determination Show Enum titles if there is a non-blank label before on the same row. Pull Request: https://projects.blender.org/blender/blender/pulls/111818
2023-09-02 05:03:56 +02:00
/* Is there a non-blank label before this button on the same row? */
const bool prior_label = but->prev && but->prev->type == UI_BTYPE_LABEL && but->prev->str[0] &&
but->prev->alignnr == but->alignnr;
Fix #115085: Multicolumn Menus without Category Names Handle menus that are meant to be multicolumn, with section dividers, but not all sections have category names, just separators. Pull Request: https://projects.blender.org/blender/blender/pulls/115102
2023-11-18 17:21:42 +01:00
if (title && title[0] && (categories == 0) && (!but->str[0] || !prior_label)) {
UI: Improved Enum Title Determination Show Enum titles if there is a non-blank label before on the same row. Pull Request: https://projects.blender.org/blender/blender/pulls/111818
2023-09-02 05:03:56 +02:00
/* Show title when no categories and calling button has no text or prior label. */
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiDefBut(
block, UI_BTYPE_LABEL, 0, title, 0, 0, UI_UNIT_X * 5, UI_UNIT_Y, nullptr, 0.0, 0.0, "");
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
uiItemS(layout);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: consistent use of tags: NOTE/TODO/FIXME/XXX Also use doxy style function reference `#` prefix chars when referencing identifiers.
2021-07-03 23:08:40 +10:00
/* NOTE: `item_array[...]` is reversed on access. */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
/* create items */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiLayout *split = uiLayoutSplit(layout, 0.0f, false);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Simplified Categorized Menus Menus with categories gain a dividing line and omit the title. Differential Revision: https://developer.blender.org/D5135 Reviewed by Brecht Van Lommel
2020-10-19 11:28:38 -07:00
bool new_column;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int column_end = 0;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiLayout *column = nullptr;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
for (int a = 0; a < totitems; a++) {
UI: Simplified Categorized Menus Menus with categories gain a dividing line and omit the title. Differential Revision: https://developer.blender.org/D5135 Reviewed by Brecht Van Lommel
2020-10-19 11:28:38 -07:00
new_column = (a == column_end);
if (new_column) {
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
/* start new column, and find out where it ends in advance, so we
* can flip the order of items properly per column */
column_end = totitems;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
for (int b = a + 1; b < totitems; b++) {
const EnumPropertyItem *item = &item_array[b];
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
/* new column on N rows or on separation label */
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
if (((b - a) % rows == 0) || (columns > 1 && !item->identifier[0] && item->name)) {
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
column_end = b;
break;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
column = uiLayoutColumn(split, false);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
const EnumPropertyItem *item = &item_array[a];
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
if (new_column && (categories > 0) && (columns > 1) && item->identifier[0]) {
UI: Simplified Categorized Menus Menus with categories gain a dividing line and omit the title. Differential Revision: https://developer.blender.org/D5135 Reviewed by Brecht Van Lommel
2020-10-19 11:28:38 -07:00
uiItemL(column, "", ICON_NONE);
uiItemS(column);
}
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
if (!item->identifier[0]) {
Fix #72093: Collapse Wide Enum Lists to One Column If a multi-column Enum menu gets too wide for the available space, collapse it to a single column. Pull Request: https://projects.blender.org/blender/blender/pulls/105386
2023-11-16 21:14:35 +01:00
if (item->name || columns > 1) {
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
if (item->icon) {
uiItemL(column, item->name, item->icon);
}
Fix #115085: Multicolumn Menus without Category Names Handle menus that are meant to be multicolumn, with section dividers, but not all sections have category names, just separators. Pull Request: https://projects.blender.org/blender/blender/pulls/115102
2023-11-18 17:21:42 +01:00
else if (item->name) {
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
/* Do not use uiItemL here, as our root layout is a menu one,
* it will add a fake blank icon! */
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
uiDefBut(block,
UI_BTYPE_LABEL,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
0,
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
item->name,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
0,
0,
Cleanup: right shift in interface code
2018-07-01 19:57:31 +02:00
UI_UNIT_X * 5,
UI_UNIT_Y,
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
0.0,
0.0,
"");
}
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
}
UI: Fix Support for Anonymous Menu Separators Re-enables support for menus to have items without identifier or name that can be used to separate sections. Differential Revision: https://developer.blender.org/D9463 Reviewed by Hans Goudey
2020-11-04 17:19:46 -08:00
uiItemS(column);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
else {
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
int icon = item->icon;
/* Use blank icon if there is none for this item (but for some other one) to make sure labels
* align. */
if (icon == ICON_NONE && has_item_with_icon) {
icon = ICON_BLANK1;
}
UI: Highlight Selected Enum Highlight the currently-selected item in enum, and some other, lists. Pull Request: https://projects.blender.org/blender/blender/pulls/111074
2023-09-01 21:33:03 +02:00
uiBut *item_but;
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
if (icon) {
UI: Highlight Selected Enum Highlight the currently-selected item in enum, and some other, lists. Pull Request: https://projects.blender.org/blender/blender/pulls/111074
2023-09-01 21:33:03 +02:00
item_but = uiDefIconTextButI(block,
UI_BTYPE_BUT_MENU,
B_NOP,
icon,
item->name,
0,
0,
UI_UNIT_X * 5,
UI_UNIT_Y,
&handle->retvalue,
item->value,
0.0,
item->description);
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
}
else {
UI: Highlight Selected Enum Highlight the currently-selected item in enum, and some other, lists. Pull Request: https://projects.blender.org/blender/blender/pulls/111074
2023-09-01 21:33:03 +02:00
item_but = uiDefButI(block,
UI_BTYPE_BUT_MENU,
B_NOP,
item->name,
0,
0,
UI_UNIT_X * 5,
UI_UNIT_X,
&handle->retvalue,
item->value,
0.0,
item->description);
}
if (item->value == current_value) {
UI: Fixes for the highlighting of Selected Enums Remove need for adding UI_BUT_LIST_ITEM, and replace use of UI_BUT_ACTIVE_DEFAULT with UI_SELECT_DRAW Pull Request: https://projects.blender.org/blender/blender/pulls/111938
2023-09-06 17:55:56 +02:00
item_but->flag |= UI_SELECT_DRAW;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_layout_set_current(block, layout);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
if (free) {
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
MEM_freeN((void *)item_array);
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
}
}
Fix #117272: Color property with popover causes Blender freeze Caused by 29f3af95272590d26f61, exposed by bff51ae66c9babf1d233. The problem was that a `uiBut` pointer was being passed to a function and then dereferenced as a `PanelType`. In the past, the button used to just have zeros where the pointer was then read from, but after the changes in the second commit, this was no longer the case. Fix by being more explicit about the argument type, and changing the argument from a button to the panel type for one callback. It's a bit complex because the panel type and panel type idname are stored in different places depending on the button type.
2024-01-18 13:54:10 -05:00
static void ui_def_but_rna__panel_type(bContext *C, uiLayout *layout, void *arg)
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
{
Fix #117272: Color property with popover causes Blender freeze Caused by 29f3af95272590d26f61, exposed by bff51ae66c9babf1d233. The problem was that a `uiBut` pointer was being passed to a function and then dereferenced as a `PanelType`. In the past, the button used to just have zeros where the pointer was then read from, but after the changes in the second commit, this was no longer the case. Fix by being more explicit about the argument type, and changing the argument from a button to the panel type for one callback. It's a bit complex because the panel type and panel type idname are stored in different places depending on the button type.
2024-01-18 13:54:10 -05:00
PanelType *panel_type = static_cast<PanelType *>(arg);
if (panel_type) {
ui_item_paneltype_func(C, layout, panel_type);
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
}
else {
Fix #117272: Color property with popover causes Blender freeze Caused by 29f3af95272590d26f61, exposed by bff51ae66c9babf1d233. The problem was that a `uiBut` pointer was being passed to a function and then dereferenced as a `PanelType`. In the past, the button used to just have zeros where the pointer was then read from, but after the changes in the second commit, this was no longer the case. Fix by being more explicit about the argument type, and changing the argument from a button to the panel type for one callback. It's a bit complex because the panel type and panel type idname are stored in different places depending on the button type.
2024-01-18 13:54:10 -05:00
uiItemL(layout, RPT_("Missing Panel"), ICON_NONE);
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
}
}
RNA: rename prop_popover_enum to prop_with_popover A version for menu's is going to be added next and we already have UILayout.prop_menu_enum. This name indicates the popover is added behavior instead of a different kind of widget.
2019-03-25 20:10:32 +11:00
void ui_but_rna_menu_convert_to_panel_type(uiBut *but, const char *panel_type)
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
{
GPencil: Refactor of Draw Engine, Vertex Paint and all internal functions This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes. Also, a huge code cleanup has been done at all levels. Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development. Differential Revision: https://developer.blender.org/D6293
2020-03-09 16:27:24 +01:00
BLI_assert(ELEM(but->type, UI_BTYPE_MENU, UI_BTYPE_COLOR));
// BLI_assert(but->menu_create_func == ui_def_but_rna__menu);
// BLI_assert((void *)but->poin == but);
RNA: rename prop_popover_enum to prop_with_popover A version for menu's is going to be added next and we already have UILayout.prop_menu_enum. This name indicates the popover is added behavior instead of a different kind of widget.
2019-03-25 20:10:32 +11:00
but->menu_create_func = ui_def_but_rna__panel_type;
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
but->func_argN = BLI_strdup(panel_type);
}
bool ui_but_menu_draw_as_popover(const uiBut *but)
{
RNA: rename prop_popover_enum to prop_with_popover A version for menu's is going to be added next and we already have UILayout.prop_menu_enum. This name indicates the popover is added behavior instead of a different kind of widget.
2019-03-25 20:10:32 +11:00
return (but->menu_create_func == ui_def_but_rna__panel_type);
UI: add UILayout.prop_popover_enum function Support for RNA enum buttons that activate popovers when clicked. This means we get useful tooltips, shortcuts and Ctrl-Wheel cycling over enum items. It also avoids inconvenient & slow access of enum values currently done via RNA type lookups on the type to get the name & icon to use for a regular popover button. Resolves T57738
2019-03-25 18:55:38 +11:00
}
RNA: add UILayout.prop_with_menu function Matches prop_with_popover, supporting menu types, useful if we want to control behavior of enum switching.
2019-03-25 20:31:06 +11:00
static void ui_def_but_rna__menu_type(bContext *C, uiLayout *layout, void *but_p)
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiBut *but = static_cast<uiBut *>(but_p);
const char *menu_type = static_cast<const char *>(but->func_argN);
RNA: add UILayout.prop_with_menu function Matches prop_with_popover, supporting menu types, useful if we want to control behavior of enum switching.
2019-03-25 20:31:06 +11:00
MenuType *mt = WM_menutype_find(menu_type, true);
if (mt) {
ui_item_menutype_func(C, layout, mt);
}
else {
char msg[256];
I18n: Go over TIP_ and IFACE_ usages, change to RPT_ when relevant The previous commit introduced a new `RPT_()` macro to translate strings which are not tooltips or regular interface elements, but longer reports or statuses. This commit uses the new macro to translate many strings all over the UI. Most of it is a simple replace from `TIP_()` or `IFACE_()` to `RPT_()`, but there are some additional changes: - A few translations inside `BKE_report()` are removed altogether because they are already handled by the translation system. - Messages inside `UI_but_disable()` are no longer translated manually, but they are handled by a new regex in the translation system. Pull Request: https://projects.blender.org/blender/blender/pulls/116804 Pull Request: https://projects.blender.org/blender/blender/pulls/116804
2024-01-11 19:49:03 +01:00
SNPRINTF(msg, RPT_("Missing Menu: %s"), menu_type);
RNA: add UILayout.prop_with_menu function Matches prop_with_popover, supporting menu types, useful if we want to control behavior of enum switching.
2019-03-25 20:31:06 +11:00
uiItemL(layout, msg, ICON_NONE);
}
}
void ui_but_rna_menu_convert_to_menu_type(uiBut *but, const char *menu_type)
{
BLI_assert(but->type == UI_BTYPE_MENU);
BLI_assert(but->menu_create_func == ui_def_but_rna__menu);
BLI_assert((void *)but->poin == but);
but->menu_create_func = ui_def_but_rna__menu_type;
but->func_argN = BLI_strdup(menu_type);
}
UI: Add extra padding to menus to draw sub-menu triangles in Shortcut strings would be offset to the left to make space for the triangles, breaking the alignment with other shortcut strings. Now this alignment is kept by making menus slightly wider if there's a sub-menu triangle visible, making room for the triangle.
2018-07-06 19:26:12 +02:00
static void ui_but_submenu_enable(uiBlock *block, uiBut *but)
{
but->flag |= UI_BUT_ICON_SUBMENU;
Cleanup: use UI_ prefix for block flag
2018-09-11 15:08:08 +10:00
block->content_hints |= UI_BLOCK_CONTAINS_SUBMENU_BUT;
UI: Add extra padding to menus to draw sub-menu triangles in Shortcut strings would be offset to the left to make space for the triangles, breaking the alignment with other shortcut strings. Now this alignment is kept by making menus slightly wider if there's a sub-menu triangle visible, making room for the triangle.
2018-07-06 19:26:12 +02:00
}
code cleanup: some style edits, also allow mul_v2_m2v2() to have the same value as in-out, since this is a convention for existing matrix functions.
2013-02-12 00:35:31 +00:00
/**
* ui_def_but_rna_propname and ui_def_but_rna
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
* both take the same args except for propname vs prop, this is done so we can
* avoid an extra lookup on 'prop' when its already available.
*
* When this kind of change won't disrupt branches, best look into making more
* of our UI functions take prop rather than propname.
*/
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
static uiBut *ui_def_but_rna(uiBlock *block,
int type,
int retval,
const char *str,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
PropertyRNA *prop,
int index,
float min,
float max,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
const PropertyType proptype = RNA_property_type(prop);
UI: remove unused freestr
2014-02-13 09:49:00 +11:00
int icon = 0;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
uiMenuCreateFunc func = nullptr;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (ELEM(type, UI_BTYPE_COLOR, UI_BTYPE_HSVCIRCLE, UI_BTYPE_HSVCUBE)) {
make sure color picker and color swatch buttons have rnaindex of -1. Some were 0 some -1, but this messed up reporting - making it think that only red was being changed for each button.
2012-12-18 17:00:49 +00:00
BLI_assert(index == -1);
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
/* use rna values if parameters are not specified */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if ((proptype == PROP_ENUM) && ELEM(type, UI_BTYPE_MENU, UI_BTYPE_ROW, UI_BTYPE_LISTROW)) {
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
bool free;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
const EnumPropertyItem *item;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_enum_items(
static_cast<bContext *>(block->evil_C), ptr, prop, &item, nullptr, &free);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int value;
/* UI_BTYPE_MENU is handled a little differently here */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (type == UI_BTYPE_MENU) {
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
value = RNA_property_enum_get(ptr, prop);
}
else {
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
value = int(max);
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use const variables
2021-01-04 17:02:13 +11:00
const int i = RNA_enum_from_value(item, value);
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
if (i != -1) {
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
if (!str) {
str = item[i].name;
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
#ifdef WITH_INTERNATIONAL
Code cleanup: UI - de-duplicate menu/row/listrow enum logic
2014-03-12 19:11:09 +11:00
str = CTX_IFACE_(RNA_property_translation_context(prop), str);
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
#endif
Code cleanup: UI - de-duplicate menu/row/listrow enum logic
2014-03-12 19:11:09 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
icon = item[i].icon;
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
}
else {
if (!str) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (type == UI_BTYPE_MENU) {
Code cleanup: UI - de-duplicate menu/row/listrow enum logic
2014-03-12 19:11:09 +11:00
str = "";
}
else {
str = RNA_property_ui_name(prop);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (type == UI_BTYPE_MENU) {
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
func = ui_def_but_rna__menu;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
if (free) {
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
MEM_freeN((void *)item);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
}
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
else {
if (!str) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
str = RNA_property_ui_name(prop);
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
}
UI: allow passing "" for icon only enum buttons and still get an icon Enum icon-only buttons were getting their strings set, then truncated with blenders string shortening methods, then not drawn because there was no room (since buttons are icon width). Modify UI code so icon-only buttons don't get names and passing "" to a button won't have its text set later on.
2014-03-12 19:24:47 +11:00
icon = RNA_property_ui_icon(prop);
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (!tip && proptype != PROP_ENUM) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
tip = RNA_property_ui_description(prop);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
float step = -1.0f;
float precision = -1.0f;
if (proptype == PROP_INT) {
int hardmin, hardmax, softmin, softmax, int_step;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
RNA_property_int_range(ptr, prop, &hardmin, &hardmax);
RNA_property_int_ui_range(ptr, prop, &softmin, &softmax, &int_step);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
if (!ELEM(type, UI_BTYPE_ROW, UI_BTYPE_LISTROW) && min == max) {
min = hardmin;
max = hardmax;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
step = int_step;
precision = 0;
}
else if (proptype == PROP_FLOAT) {
float hardmin, hardmax, softmin, softmax;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
RNA_property_float_range(ptr, prop, &hardmin, &hardmax);
RNA_property_float_ui_range(ptr, prop, &softmin, &softmax, &step, &precision);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
if (!ELEM(type, UI_BTYPE_ROW, UI_BTYPE_LISTROW) && min == max) {
min = hardmin;
max = hardmax;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
else if (proptype == PROP_STRING) {
min = 0;
max = RNA_property_string_maxlength(prop);
/* NOTE: 'max' may be zero (code for dynamically resized array). */
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
/* now create button */
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, type, retval, str, x, y, width, height, nullptr, min, max, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
if (but->type == UI_BTYPE_NUM) {
Cleanup: Typo: `overriden` -> `overridden`.
2020-12-28 10:07:36 +01:00
/* Set default values, can be overridden later. */
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
UI_but_number_step_size_set(but, step);
UI_but_number_precision_set(but, precision);
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
}
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
else if (but->type == UI_BTYPE_NUM_SLIDER) {
/* Set default values, can be overridden later. */
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
UI_but_number_slider_step_size_set(but, step);
UI_but_number_slider_precision_set(but, precision);
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
}
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->rnapoin = *ptr;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
but->rnaprop = prop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (RNA_property_array_check(but->rnaprop)) {
but->rnaindex = index;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
else {
Revert "Cleanup: consistently use rnaindex -1 to mean the no or entire array" This reverts commit 8ed65fe6de9a386f99b0ed7b255f76beaa86ae5b. Fix #108553: Alt + value change doesn't work for various inputs Fix #108621: Driven values are no longer marked in purple
2023-06-06 11:30:49 +02:00
but->rnaindex = 0;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: support editing >400 length text buttons RNA could define strings as dynamically sized, but the interface ignored this and clamped them to UI_MAX_DRAW_STR. Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
2015-11-10 08:35:12 +11:00
if (icon) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (type == UI_BTYPE_MENU) {
Cleanup: rename uiBut.dt, uiBlock.dt to 'emboss' Use 'emboss' instead of 'draw_type' as enum, layout & functions use the term emboss. This issue was noted by @Poulpator in D8414, as `dt` is also an abbreviation for delta-time.
2020-07-29 12:05:27 +10:00
if (but->emboss == UI_EMBOSS_PULLDOWN) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
ui_but_submenu_enable(block, but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
Fix T54580: Pointer buttons skip undo push
2018-12-03 18:43:33 +11:00
else if (type == UI_BTYPE_SEARCH_MENU) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (proptype == PROP_POINTER) {
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
/* Search buttons normally don't get undo, see: #54580. */
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->flag |= UI_BUT_UNDO;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
}
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
const char *info;
if (but->rnapoin.data && !RNA_property_editable_info(&but->rnapoin, prop, &info)) {
Cleanup: Add/use function to disable buttons with a disabled hint We do this in a couple of places, so it's worth having the logic wrapped into a function. Also, the only way to set the disabled hint for a button from outside of `interface/` was through `UI_block_lock_set()`/`UI_block_lock_clear()`, for which the usage isn't obvious when you just try to disable a single button.
2020-09-03 17:39:57 +02:00
UI_but_disable(but, info);
UI: various changes * View2D to region now returns ints instead of shorts. * Use "Numpad" instead of "Pad" in automatic keymap menu info. * Menus can now use buttons other than BUTM and SEPR, in particular TOG and ROW are now supported instead of flipping bits manually. * Added a simpler uiDefMenu* api for making menus now, and it only supports Operator and RNA buttons at the moment, will be used in next commit. Not sure how this will evolve .. makes menu code look cleaner anyways. * Ensure that interface code doesn't crash when getting unknown Operators and RNA properties, and display their buttons grayed out in that case.
2009-01-15 04:13:38 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Allow UI to pass focused data-block to operators via context This is similar to c4a2067130130d, but applies to the general UI and is only about single data-blocks. Here there was a similar problem: How can buttons pass the data they represent to operators? We currently resort to ugly ad-hoc solutions like `UI_context_active_but_get_tab_ID()`. So the operator would need to know that it is executed on a tab button that represents a data-block. A single button can now hand operators a data-block to operate on. The operator can request it via the "id" context member (`CTX_data_pointer_get_type(C, "id", &RNA_ID)` in C, `bpy.context.id` in .py). In this commit, it is already set in the following places: * Generic RNA button code sets it to the pointed to data-block, if the button represents a data-block RNA pointer property. (I.e for general data-block search buttons.) * Data-block selectors (`templateID`) set it to the currently active data-block. * The material slot UI-List sets it for each slot to the material it represents. The button context menu code is modified so its operators use the context set for the layout of its parent button (i.e. `layout.context_pointer_set()`). No user visible changes. This new design isn't actually used yet. It will be soon for asset operators. Reviewed as part of https://developer.blender.org/D9717. Reviewed by: Brecht Van Lommel
2020-12-11 22:20:31 +01:00
if (proptype == PROP_POINTER) {
/* If the button shows an ID, automatically set it as focused in context so operators can
Cleanup: full sentences in comments, improve comment formatting
2021-06-26 21:35:18 +10:00
* access it. */
UI: Allow UI to pass focused data-block to operators via context This is similar to c4a2067130130d, but applies to the general UI and is only about single data-blocks. Here there was a similar problem: How can buttons pass the data they represent to operators? We currently resort to ugly ad-hoc solutions like `UI_context_active_but_get_tab_ID()`. So the operator would need to know that it is executed on a tab button that represents a data-block. A single button can now hand operators a data-block to operate on. The operator can request it via the "id" context member (`CTX_data_pointer_get_type(C, "id", &RNA_ID)` in C, `bpy.context.id` in .py). In this commit, it is already set in the following places: * Generic RNA button code sets it to the pointed to data-block, if the button represents a data-block RNA pointer property. (I.e for general data-block search buttons.) * Data-block selectors (`templateID`) set it to the currently active data-block. * The material slot UI-List sets it for each slot to the material it represents. The button context menu code is modified so its operators use the context set for the layout of its parent button (i.e. `layout.context_pointer_set()`). No user visible changes. This new design isn't actually used yet. It will be soon for asset operators. Reviewed as part of https://developer.blender.org/D9717. Reviewed by: Brecht Van Lommel
2020-12-11 22:20:31 +01:00
const PointerRNA pptr = RNA_property_pointer_get(ptr, prop);
if (pptr.data && RNA_struct_is_ID(pptr.type)) {
Cleanup: UI: Store uiBlock context stores in vector instead of list Also fix an issue where contest stores were copied with the "used" flag set after 7d7e90ca685954409ece007d03d2e93860a6cef7.
2023-08-31 10:46:53 -04:00
but->context = CTX_store_add(block->contexts, "id", &pptr);
UI: Allow UI to pass focused data-block to operators via context This is similar to c4a2067130130d, but applies to the general UI and is only about single data-blocks. Here there was a similar problem: How can buttons pass the data they represent to operators? We currently resort to ugly ad-hoc solutions like `UI_context_active_but_get_tab_ID()`. So the operator would need to know that it is executed on a tab button that represents a data-block. A single button can now hand operators a data-block to operate on. The operator can request it via the "id" context member (`CTX_data_pointer_get_type(C, "id", &RNA_ID)` in C, `bpy.context.id` in .py). In this commit, it is already set in the following places: * Generic RNA button code sets it to the pointed to data-block, if the button represents a data-block RNA pointer property. (I.e for general data-block search buttons.) * Data-block selectors (`templateID`) set it to the currently active data-block. * The material slot UI-List sets it for each slot to the material it represents. The button context menu code is modified so its operators use the context set for the layout of its parent button (i.e. `layout.context_pointer_set()`). No user visible changes. This new design isn't actually used yet. It will be soon for asset operators. Reviewed as part of https://developer.blender.org/D9717. Reviewed by: Brecht Van Lommel
2020-12-11 22:20:31 +01:00
}
}
Fix T54580: Pointer buttons skip undo push
2018-12-03 18:43:33 +11:00
if (but->flag & UI_BUT_UNDO && (ui_but_is_rna_undo(but) == false)) {
but->flag &= ~UI_BUT_UNDO;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
/* If this button uses units, calculate the step from this */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if ((proptype == PROP_FLOAT) && ui_but_is_unit(but)) {
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
if (type == UI_BTYPE_NUM) {
uiButNumber *number_but = (uiButNumber *)but;
number_but->step_size = ui_get_but_step_unit(but, number_but->step_size);
}
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
if (type == UI_BTYPE_NUM_SLIDER) {
uiButNumberSlider *number_but = (uiButNumberSlider *)but;
number_but->step_size = ui_get_but_step_unit(but, number_but->step_size);
}
UI: Fix for rna-enum submenus not showing a right arrow
2014-02-20 13:30:52 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Add template_search (version of template_ID for non-IDs) Adds a version of template_ID that can be used for non-ID properties. The property to search for and the collection to search in has to be passed to it. Like template_ID it also takes arguments to define a 'new' and 'unlink' operator. They will be displayed as icon-only buttons then. Also added a version that can display preview thumbnails. Had to do some additional changes to make text-buttons support displaying/modifying empty RNA properties. This will be needed for workspaces, see D2451. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D2666
2017-05-12 01:42:42 +02:00
if (func) {
but->menu_create_func = func;
but->poin = (char *)but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: Add template_search (version of template_ID for non-IDs) Adds a version of template_ID that can be used for non-ID properties. The property to search for and the collection to search in has to be passed to it. Like template_ID it also takes arguments to define a 'new' and 'unlink' operator. They will be displayed as icon-only buttons then. Also added a version that can display preview thumbnails. Had to do some additional changes to make text-buttons support displaying/modifying empty RNA properties. This will be needed for workspaces, see D2451. Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D2666
2017-05-12 01:42:42 +02:00
return but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
RNA/UI: Allow displaying in tooltip why RNA property isn't editable This commit allows RNA properties to return additional info on their editable state which may then be displayed in tooltips. To show how it works, it also adds some info for the editable check of proxies. For generally un-editable properties or properties of a linked data-block, RNA returns default strings. | {F362785} | {F362786} | {F362787} | Reviewed by brecht, thanks! Differential Revision: https://developer.blender.org/D2243
2016-09-22 00:10:53 +02:00
static uiBut *ui_def_but_rna_propname(uiBlock *block,
int type,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int retval,
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
const char *str,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
int x,
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
int y,
short width,
short height,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
PointerRNA *ptr,
const char *propname,
int index,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
float min,
float max,
UI: refactor menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
const char *tip)
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
{
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
PropertyRNA *prop = RNA_struct_find_property(ptr, propname);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (prop) {
but = ui_def_but_rna(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
make ui_def_but_rna into 2 functions, once which takes a prop, another which takes a propname, no functional change yet but lets us avoid duplicate hash lookups.
2011-08-06 14:57:55 +00:00
else {
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
but = ui_def_but(block, type, retval, propname, x, y, width, height, nullptr, min, max, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
I18N/UI Messages fixes.
2024-02-12 12:01:02 +01:00
UI_but_disable(but, N_("Unknown Property"));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
return but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
RNA/UI: Allow displaying in tooltip why RNA property isn't editable This commit allows RNA properties to return additional info on their editable state which may then be displayed in tooltips. To show how it works, it also adds some info for the editable check of proxies. For generally un-editable properties or properties of a linked data-block, RNA returns default strings. | {F362785} | {F362786} | {F362787} | Reviewed by brecht, thanks! Differential Revision: https://developer.blender.org/D2243
2016-09-22 00:10:53 +02:00
static uiBut *ui_def_but_operator_ptr(uiBlock *block,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int type,
RNA/UI: Allow displaying in tooltip why RNA property isn't editable This commit allows RNA properties to return additional info on their editable state which may then be displayed in tooltips. To show how it works, it also adds some info for the editable check of proxies. For generally un-editable properties or properties of a linked data-block, RNA returns default strings. | {F362785} | {F362786} | {F362787} | Reviewed by brecht, thanks! Differential Revision: https://developer.blender.org/D2243
2016-09-22 00:10:53 +02:00
wmOperatorType *ot,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
Python API: implement an Operator callback for dynamic description. Blender UI Layout API allows supplying parameters to operators via button definitions. If an operator behavior strongly depends on its parameters, it may be difficult to write a tooltip that covers all of its operation modes. Thus it is useful to provide a way for the operator to produce different descriptions based on the input info. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D5709
2019-09-06 16:26:10 +03:00
if ((!tip || tip[0] == '\0') && ot && ot->srna && !ot->get_description) {
i18n stuff: adds translation_context to RNA structs (used for there ui name), and a first default "Operator" one for all operators' label. The fact is, operators' label are nearly always verbs, while properties labels are nearly always nouns. So this should already solve many translations' problems regarding noun/verb confusion. This commit also simplifies a bit i18n usage: *Now IFACE_ and TIP_ macros (or there context versions, CTX_IFACE_/TIP_) are used nearly everywhere (with one exception, where code is a bit complex and needs to manually test whether ui/tip translations is allowed, so no need to redo it later through those macros). *Also, those macros are now defined to NOP in case WITH_INTERNATIONAL is false, which avoid testing that define everywhere in code!
2012-03-16 15:39:25 +00:00
tip = RNA_struct_ui_description(ot->srna);
* Added description string to operator types, should be set along with ot->idname when defining ops. * User interface uses this as a tooltip when NULL or "" is given. * Python doc generation includes this description * Python defined ops take the description as an argument. * NULL check to image_ops.c, was crashing on exit when there was an image open.
2009-02-12 03:39:56 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, type, -1, str, x, y, width, height, nullptr, 0, 0, tip);
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->optype = ot;
but->opcontext = opcontext;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
but->flag &= ~UI_BUT_UNDO; /* no need for ui_but_is_rna_undo(), we never need undo here */
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
/* Enable quick tooltip label if this is a tool button without a label. */
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
if (str.is_empty() && !ui_block_is_popover(block) && UI_but_is_tool(but)) {
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
UI_but_drawflag_enable(but, UI_BUT_HAS_TOOLTIP_LABEL);
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!ot) {
Cleanup: Add/use function to disable buttons with a disabled hint We do this in a couple of places, so it's worth having the logic wrapped into a function. Also, the only way to set the disabled hint for a button from outside of `interface/` was through `UI_block_lock_set()`/`UI_block_lock_clear()`, for which the usage isn't obvious when you just try to disable a single button.
2020-09-03 17:39:57 +02:00
UI_but_disable(but, "");
UI: various changes * View2D to region now returns ints instead of shorts. * Use "Numpad" instead of "Pad" in automatic keymap menu info. * Menus can now use buttons other than BUTM and SEPR, in particular TOG and ROW are now supported instead of flipping bits manually. * Added a simpler uiDefMenu* api for making menus now, and it only supports Operator and RNA buttons at the moment, will be used in next commit. Not sure how this will evolve .. makes menu code look cleaner anyways. * Ensure that interface code doesn't crash when getting unknown Operators and RNA properties, and display their buttons grayed out in that case.
2009-01-15 04:13:38 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefBut(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, type, retval, str, x, y, width, height, poin, min, max, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
return but;
}
UI: Larger Alert Icons Adding a set of larger icons for use in informational dialogs. Differential Revision: https://developer.blender.org/D6859 Reviewed by Campbell Barton
2020-03-14 11:05:09 -07:00
uiBut *uiDefButImage(
uiBlock *block, void *imbuf, int x, int y, short width, short height, const uchar color[4])
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, UI_BTYPE_IMAGE, 0, "", x, y, width, height, imbuf, 0, 0, "");
UI: Larger Alert Icons Adding a set of larger icons for use in informational dialogs. Differential Revision: https://developer.blender.org/D6859 Reviewed by Campbell Barton
2020-03-14 11:05:09 -07:00
if (color) {
copy_v4_v4_uchar(but->col, color);
}
else {
but->col[0] = 255;
but->col[1] = 255;
but->col[2] = 255;
but->col[3] = 255;
}
ui_but_update(but);
return but;
}
uiBut *uiDefButAlert(uiBlock *block, int icon, int x, int y, short width, short height)
{
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
ImBuf *ibuf = UI_icon_alert_imbuf_get((eAlertIcon)icon);
UI: Remove Blender Logo Alert Icon As discussed in the UI Module Meeting we don't have an acceptable use case for dialogs that use the Blender logo. Removing this image from the project since this is now exposed through dialog customization. Pull Request: https://projects.blender.org/blender/blender/pulls/117676
2024-01-30 20:22:38 +01:00
if (ibuf) {
bTheme *btheme = UI_GetTheme();
return uiDefButImage(block, ibuf, x, y, width, height, btheme->tui.wcol_menu_back.text);
}
return nullptr;
UI: Larger Alert Icons Adding a set of larger icons for use in informational dialogs. Differential Revision: https://developer.blender.org/D6859 Reviewed by Campbell Barton
2020-03-14 11:05:09 -07:00
}
style cleanup
2013-10-21 23:35:08 +00:00
/**
* if \a _x_ is a power of two (only one bit) return the power,
style cleanup: interface
2012-03-30 01:51:25 +00:00
* otherwise return -1.
style cleanup
2013-10-21 23:35:08 +00:00
*
* for powers of two:
* \code{.c}
* ((1 << findBitIndex(x)) == x);
* \endcode
style cleanup: interface
2012-03-30 01:51:25 +00:00
*/
Cleanup: use typed unsigned ints
2019-01-04 11:05:53 +11:00
static int findBitIndex(uint x)
whitespace edits, make formatting for functions consustent at least within the file.
2011-09-28 05:53:40 +00:00
{
static functions for getting power of 2 values were being copied about too much, add to the BLI_math api. - is_power_of_2_i - power_of_2_min_i - power_of_2_max_i
2011-12-16 09:25:07 +00:00
if (!x || !is_power_of_2_i(x)) { /* is_power_of_2_i(x) strips lowest bit */
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
return -1;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
int idx = 0;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (x & 0xFFFF0000) {
idx += 16;
x >>= 16;
}
if (x & 0xFF00) {
idx += 8;
x >>= 8;
}
if (x & 0xF0) {
idx += 4;
x >>= 4;
}
if (x & 0xC) {
idx += 2;
x >>= 2;
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
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (x & 0x2) {
idx += 1;
}
return idx;
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
}
Cleanup: correct spelling in comments
2021-02-05 16:23:34 +11:00
/* Auto-complete helper functions. */
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 AutoComplete {
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
size_t maxncpy;
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
int matches;
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
char *truncate;
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
const char *startname;
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
};
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
AutoComplete *UI_autocomplete_begin(const char *startname, size_t maxncpy)
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
{
AutoComplete *autocpl;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
autocpl = MEM_cnew<AutoComplete>(__func__);
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
autocpl->maxncpy = maxncpy;
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
autocpl->matches = 0;
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
autocpl->truncate = static_cast<char *>(MEM_callocN(sizeof(char) * maxncpy, __func__));
style cleanup: interface
2012-03-30 01:51:25 +00:00
autocpl->startname = startname;
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
return autocpl;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_autocomplete_update_name(AutoComplete *autocpl, const char *name)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *truncate = autocpl->truncate;
const char *startname = autocpl->startname;
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
int match_index = 0;
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
for (int a = 0; a < autocpl->maxncpy - 1; a++) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (startname[a] == 0 || startname[a] != name[a]) {
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
match_index = a;
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
break;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
}
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05: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
/* found a match */
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
if (startname[match_index] == 0) {
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
autocpl->matches++;
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
/* first match */
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (truncate[0] == 0) {
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
BLI_strncpy(truncate, name, autocpl->maxncpy);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
else {
/* remove from truncate what is not in bone->name */
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
for (int a = 0; a < autocpl->maxncpy - 1; a++) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (name[a] == 0) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
truncate[a] = 0;
UI * Search popup + autocomplete for bones, vertex groups, etc. This is done with layout.item_pointerR, specifying an RNA collection to take the items from. Used by constraints and modifiers. * Some tests with the List template, ignore those for now..
2009-06-27 01:15:31 +00:00
break;
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
if (truncate[a] != name[a]) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
truncate[a] = 0;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11: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
}
}
}
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int UI_autocomplete_end(AutoComplete *autocpl, char *autoname)
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
{
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
int match = AUTOCOMPLETE_NO_MATCH;
fix for filesel autocomplete, it had the annoying behavior if you entered in a non-existing name, of executing it and then asking to add the dir.
2013-06-19 11:53:48 +00:00
if (autocpl->truncate[0]) {
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
if (autocpl->matches == 1) {
match = AUTOCOMPLETE_FULL_MATCH;
Code Cleanup: style, spelling and pep8 edits
2013-11-20 03:38:18 +11:00
}
else {
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
match = AUTOCOMPLETE_PARTIAL_MATCH;
}
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
BLI_strncpy(autoname, autocpl->truncate, autocpl->maxncpy);
fix for filesel autocomplete, it had the annoying behavior if you entered in a non-existing name, of executing it and then asking to add the dir.
2013-06-19 11:53:48 +00:00
}
2.50: svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r18677:19317 Notes: * Sequence transform strip uses G.scene global, this is commented out now, should be fixed. * Etch-a-ton code was most difficult to merge. The files already in 2.5 got merged, but no new files were added. Calls to these files are commented out with "XXX etch-a-ton". editarmature.c and transform_snap.c were complex to merge. Martin, please check? * Game engine compiles and links again here for scons/make/cmake (player still fails to link).
2009-03-17 21:44:58 +00:00
else {
Cleanup: Grammar: its self vs. itself
2022-01-23 22:34:56 -06:00
if (autoname != autocpl->startname) { /* don't copy a string over itself */
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
BLI_strncpy(autoname, autocpl->startname, autocpl->maxncpy);
fix for filesel autocomplete, it had the annoying behavior if you entered in a non-existing name, of executing it and then asking to add the dir.
2013-06-19 11:53:48 +00:00
}
2.50: svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r18677:19317 Notes: * Sequence transform strip uses G.scene global, this is commented out now, should be fixed. * Etch-a-ton code was most difficult to merge. The files already in 2.5 got merged, but no new files were added. Calls to these files are commented out with "XXX etch-a-ton". editarmature.c and transform_snap.c were complex to merge. Martin, please check? * Game engine compiles and links again here for scons/make/cmake (player still fails to link).
2009-03-17 21:44:58 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
MEM_freeN(autocpl->truncate);
MEM_freeN(autocpl);
Fix: tab completing a filepath name in file browsers asks to create a new directory if name was not fully matched When hitting tab to complete a directory name in the filepath field in the filebrowser Blender shows a "create new directory?" popup, if the beginning of directory name typed in the field matches many entries. For example if you have directories in the open directory called "test123" and "test456", typing "te", tab would complete up to "test", but ask to create a new folder with the name "test". This patch unsets the boolean storing the info about changing filepath if the folder with the completed name does not exist. Reviewed By: brecht Differential Revision: http://developer.blender.org/D10
2013-11-19 16:31:48 +01:00
return match;
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
}
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
#define PREVIEW_TILE_PAD (0.15f * UI_UNIT_X)
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
int UI_preview_tile_size_x(const int size_px)
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
{
const float pad = PREVIEW_TILE_PAD;
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
return round_fl_to_int((size_px / 20.0f) * UI_UNIT_X + 2.0f * pad);
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
}
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
int UI_preview_tile_size_y(const int size_px)
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
{
Fix incorrect preview tile button size label height Mismatch between what drawing assumes and what the function to query the full preview tile uses. This would cause previews to be scaled down because the button wasn't tall enough. Only affected the asset shelf and the asset view template.
2023-09-20 20:06:25 +02:00
const float font_height = UI_UNIT_Y;
Cleanup: reduce line wrapping caused by trailing comments
2023-05-02 10:18:39 +10:00
/* Add some extra padding to make things less tight vertically. */
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
const float pad = PREVIEW_TILE_PAD;
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
return round_fl_to_int(UI_preview_tile_size_y_no_label(size_px) + font_height + pad);
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
}
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
int UI_preview_tile_size_y_no_label(const int size_px)
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
{
const float pad = PREVIEW_TILE_PAD;
UI: Asset Shelf Support (Experimental Feature) No user visible changes expected, except of new experimental feature option. ------------------------------------------------------------------------------ This introduces asset shelves as a new standard UI element for accessing assets. Based on the current context (like the active mode and/or tool), they can provide assets for specific workflows/tasks. As such they are more limited in functionality than the asset browser, but a lot more efficient for certain tasks. The asset shelf is developed as part of the brush assets project (see #101895), but is also meant to replace the current pose library UI. Support for asset shelves can quite easily be added to different editor types, the following commit will add support for the 3D View. If an editor type supports asset shelves, add-ons can chose to register an asset shelf type for an editor with just a few lines of Python. It should be possible to entirely remove `UILayout.asset_view_template()` once asset shelves are non-experimental. Some changes are to be expected still, see #107881. Task: #102879 Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/ Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/ Pull Request: #104831
2023-08-03 16:54:39 +02:00
return round_fl_to_int((size_px / 20.0f) * UI_UNIT_Y + 2.0f * pad);
UI: Add initial "grid view" Part of T98560. See https://wiki.blender.org/wiki/Source/Interface/Views Adds all the basic functionality needed for grid views. They display items in a grid of rows and columns, typically with a preview image and a label underneath. Think of the main region in the Asset Browser. Current features: - Active item - Notifier listening (also added this to the tree view) - Performance: Skip adding buttons that are not scrolled into view (solves performance problems for big asset libraries, for example). - Custom item size - Preview items (items that draw a preview with a label underneath) - Margins between items scale so the entire region width is filled with column, rather than leaving a big empty block at the right if there's not enough space for another column (like the File and current Asset Browser does it). - "Data-View Item" theme colors. Not shown in the UI yet. No user visible changes expected since the grid views aren't used for anything yet. This was developed as part of a rewrite of the Asset Browser UI (`asset-browser-grid-view` branch), see T95653. There's no reason to keep this part in a branch, continuing development in master makes things easier. Grid and tree views have a lot of very similar code, so I'm planning to unify them to a degree. I kept things separate for the start to first find out how much and what exactly makes sense to override.
2022-06-16 11:29:20 +02:00
}
#undef PREVIEW_TILE_PAD
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
static void ui_but_update_and_icon_set(uiBut *but, int icon)
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (icon) {
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
static uiBut *uiDefButBit(uiBlock *block,
int type,
int bit,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int bitIdx = findBitIndex(bit);
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (bitIdx == -1) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return uiDefBut(block,
type | UI_BUT_POIN_BIT | bitIdx,
retval,
str,
x,
y,
width,
height,
poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButF(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
float *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefBut(block,
type | UI_BUT_POIN_FLOAT,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButI(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
int *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefBut(block,
type | UI_BUT_POIN_INT,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButBitI(uiBlock *block,
int type,
int bit,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
int *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefButBit(block,
type | UI_BUT_POIN_INT,
bit,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButS(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
short *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefBut(block,
type | UI_BUT_POIN_SHORT,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButBitS(uiBlock *block,
int type,
int bit,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
short *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefButBit(block,
type | UI_BUT_POIN_SHORT,
bit,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButC(uiBlock *block,
int type,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
char *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefBut(block,
type | UI_BUT_POIN_CHAR,
retval,
str,
x,
y,
width,
height,
(void *)poin,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
min,
max,
tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButBitC(uiBlock *block,
int type,
int bit,
int retval,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
char *poin,
float min,
float max,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
return uiDefButBit(block,
type | UI_BUT_POIN_CHAR,
bit,
retval,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButR(uiBlock *block,
int type,
int retval,
const char *str,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
const char *propname,
int index,
float min,
float max,
const char *tip)
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna_propname(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, str, x, y, width, height, ptr, propname, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButR_prop(uiBlock *block,
int type,
int retval,
const char *str,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
PropertyRNA *prop,
int index,
float min,
float max,
const char *tip)
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(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
return but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButO_ptr(uiBlock *block,
int type,
wmOperatorType *ot,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
const StringRef str,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
int x,
int y,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
short width,
short height,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_operator_ptr(block, type, ot, opcontext, str, x, y, width, height, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefButO(uiBlock *block,
int type,
const char *opname,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
const char *str,
int x,
int y,
short width,
short height,
const char *tip)
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30:07 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmOperatorType *ot = WM_operatortype_find(opname, false);
if (str == nullptr && ot == nullptr) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
str = opname;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
return uiDefButO_ptr(block, type, ot, opcontext, str, x, y, width, height, tip);
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30: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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconBut(uiBlock *block,
int type,
int retval,
int icon,
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, type, retval, "", x, y, width, height, poin, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
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
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
static uiBut *uiDefIconButBit(uiBlock *block,
int type,
int bit,
int retval,
int icon,
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
Cleanup: use const variables in interface code
2020-08-26 10:11:13 +10:00
const int bitIdx = findBitIndex(bit);
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (bitIdx == -1) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
return nullptr;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return uiDefIconBut(block,
type | UI_BUT_POIN_BIT | bitIdx,
retval,
icon,
x,
y,
width,
height,
poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButI(uiBlock *block,
int type,
int retval,
int icon,
int x,
int y,
short width,
short height,
int *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconBut(block,
type | UI_BUT_POIN_INT,
retval,
icon,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButBitI(uiBlock *block,
int type,
int bit,
int retval,
int icon,
int x,
int y,
short width,
short height,
int *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconButBit(block,
type | UI_BUT_POIN_INT,
bit,
retval,
icon,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButS(uiBlock *block,
int type,
int retval,
int icon,
int x,
int y,
short width,
short height,
short *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconBut(block,
type | UI_BUT_POIN_SHORT,
retval,
icon,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButBitS(uiBlock *block,
int type,
int bit,
int retval,
int icon,
int x,
int y,
short width,
short height,
short *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconButBit(block,
type | UI_BUT_POIN_SHORT,
bit,
retval,
icon,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButBitC(uiBlock *block,
int type,
int bit,
int retval,
int icon,
int x,
int y,
short width,
short height,
char *poin,
float min,
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
float max,
const char *tip)
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconButBit(block,
type | UI_BUT_POIN_CHAR,
bit,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
retval,
icon,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButR(uiBlock *block,
int type,
int retval,
int icon,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
const char *propname,
int index,
float min,
float max,
const char *tip)
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna_propname(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, "", x, y, width, height, ptr, propname, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
return but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButR_prop(uiBlock *block,
int type,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int retval,
int icon,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
int x,
int y,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
short width,
short height,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
PointerRNA *ptr,
PropertyRNA *prop,
int index,
float min,
float max,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
const char *tip)
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, "", x, y, width, height, ptr, prop, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButO_ptr(uiBlock *block,
int type,
wmOperatorType *ot,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int icon,
int x,
int y,
short width,
short height,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_operator_ptr(block, type, ot, opcontext, "", x, y, width, height, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconButO(uiBlock *block,
int type,
const char *opname,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int icon,
int x,
int y,
short width,
short height,
const char *tip)
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30:07 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmOperatorType *ot = WM_operatortype_find(opname, false);
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
return uiDefIconButO_ptr(block, type, ot, opcontext, icon, x, y, width, height, tip);
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30: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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextBut(uiBlock *block,
int type,
int retval,
int icon,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
void *poin,
float min,
float max,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, type, retval, str, x, y, width, height, poin, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
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
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextButI(uiBlock *block,
int type,
int retval,
int icon,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
int *poin,
float min,
float max,
const char *tip)
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
{
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
return uiDefIconTextBut(block,
type | UI_BUT_POIN_INT,
retval,
icon,
str,
x,
y,
width,
height,
(void *)poin,
min,
max,
tip);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextButR(uiBlock *block,
int type,
int retval,
int icon,
const char *str,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
const char *propname,
int index,
float min,
float max,
const char *tip)
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna_propname(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, str, x, y, width, height, ptr, propname, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextButR_prop(uiBlock *block,
int type,
int retval,
int icon,
const char *str,
int x,
int y,
short width,
short height,
PointerRNA *ptr,
PropertyRNA *prop,
int index,
float min,
float max,
const char *tip)
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_rna(
Cleanup: UI Remove more unnecessary a1 and a2 parameters Similar to 5155feeeb8a00f3a9bff. These had values without any meeting, almost completely just 0 or -1 (which meant "find good values if possible" anyway).
2024-02-05 14:38:05 -05:00
block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
return but;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextButO_ptr(uiBlock *block,
int type,
wmOperatorType *ot,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int icon,
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
const StringRef str,
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
int x,
int y,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
short width,
short height,
const char *tip)
UI: added the following functions to create buttons for RNA properties and for operators. RNA property buttons will automatically fill in the label, min/max, etc if they are not specified. Operator menu buttons will look up the key combination in the handlers and add it automatically. uiDefButR, uiDefIconButR, uiDefIconTextButR uiDefButO, uiDefIconButO, uiDefIconTextButO uiDefButO takes a context pointer to do the key lookup, don't really like this..
2008-12-16 07:55:43 +00:00
{
Cleanup: Declare variables where initialized, lower scope Also use "r_" prefix for return arguments in a few places.
2020-09-25 14:57:34 -05:00
uiBut *but = ui_def_but_operator_ptr(block, type, ot, opcontext, str, x, y, width, height, tip);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update_and_icon_set(but, icon);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
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
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextButO(uiBlock *block,
int type,
const char *opname,
Cleanup (UI): Add/use type for operator context enum Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX` operator context enum. This adds type safety, allows the compiler to produce better warnings and helps understanding what a variable is for. Differential Revision: https://developer.blender.org/D13113 Reviewed by: Campbell Barton
2021-11-05 14:56:22 +01:00
wmOperatorCallContext opcontext,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int icon,
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30:07 +00:00
{
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
wmOperatorType *ot = WM_operatortype_find(opname, false);
Refactor: UI: Pass StringRef to more button definition functions Similar to 9c3aa8b8240967f44d43. This time there is one null argument that has to be changed. It was simple to just move the logic to that one caller.
2024-02-01 14:40:33 -05:00
if (str.is_empty()) {
Various icon adjustments
2017-03-17 16:47:19 +03:00
return uiDefIconButO_ptr(block, type, ot, opcontext, icon, x, y, width, height, tip);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
return uiDefIconTextButO_ptr(block, type, ot, opcontext, icon, str, x, y, width, height, tip);
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30: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
/* END Button containing both string label and icon */
/* cruft to make uiBlock and uiBut private */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int UI_blocklist_min_y_get(ListBase *lb)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
int min = 0;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI Code Quality: Use LISTBASE_FOREACH in interface directory I only skipped a few loops in the monstrous ui_handle_menu_event function. Also, I only changed variable names where necessary to prevent redeclarations. Differential Revision: https://developer.blender.org/D8586
2020-08-18 21:46:29 -04:00
LISTBASE_FOREACH (uiBlock *, block, lb) {
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
if (block == lb->first || block->rect.ymin < min) {
use rctf struct for UI buttons and blocks, easier to read and means we can use BLI_rctf functions.
2012-08-18 16:53:46 +00:00
min = block->rect.ymin;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
return min;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_direction_set(uiBlock *block, char direction)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->direction = direction;
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_flag_enable(uiBlock *block, int flag)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->flag |= flag;
UI: * Screen level regions created for menus are now a separate CTX_wm_menu in the context, so they don't interfere with existing regions. * Fix context in popup menus to always come from the area and region the popup was opened from. * Removed some unused context stuff: tasks and reports. The places that were using context reports were using it wrong anyway. * Fix F6 closing immediately after editing a button, by making uiBlockSetFlag not clear existing flags anymore. * Don't use ":" in boolean X/Y/Z buttons.
2009-03-25 20:49:15 +00:00
}
2.5 More cleanup! - removed old UI font completely, including from uiBeginBlock - emboss hints for uiBlock only have three types now; Regular, Pulldown, or "Nothing" (only icon/text) - removed old font path from Userdef - removed all old button theme hinting - removed old "auto block" to merge buttons in groups (was only in use for radiosity buttons) And went over all warnings. One hooray for make giving clean output :) Well, we need uniform definitions for warnings, so people at least fix them... here's the real bad bugs I found: - in mesh code, a call to editmesh mixed *em and *me - in armature, ED_util.h was not included, so no warnings for wrong call to ED_undo_push() - The extern Py api .h was not included in the bpy_interface.c, showing a several calls using different args. Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_flag_disable(uiBlock *block, int flag)
UI: * Screen level regions created for menus are now a separate CTX_wm_menu in the context, so they don't interfere with existing regions. * Fix context in popup menus to always come from the area and region the popup was opened from. * Removed some unused context stuff: tasks and reports. The places that were using context reports were using it wrong anyway. * Fix F6 closing immediately after editing a button, by making uiBlockSetFlag not clear existing flags anymore. * Don't use ":" in boolean X/Y/Z buttons.
2009-03-25 20:49:15 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->flag &= ~flag;
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
}
2.5 More cleanup! - removed old UI font completely, including from uiBeginBlock - emboss hints for uiBlock only have three types now; Regular, Pulldown, or "Nothing" (only icon/text) - removed old font path from Userdef - removed all old button theme hinting - removed old "auto block" to merge buttons in groups (was only in use for radiosity buttons) And went over all warnings. One hooray for make giving clean output :) Well, we need uniform definitions for warnings, so people at least fix them... here's the real bad bugs I found: - in mesh code, a call to editmesh mixed *em and *me - in armature, ED_util.h was not included, so no warnings for wrong call to ED_undo_push() - The extern Py api .h was not included in the bpy_interface.c, showing a several calls using different args. Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
void UI_but_flag_enable(uiBut *but, int flag)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->flag |= flag;
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
}
2.5 More cleanup! - removed old UI font completely, including from uiBeginBlock - emboss hints for uiBlock only have three types now; Regular, Pulldown, or "Nothing" (only icon/text) - removed old font path from Userdef - removed all old button theme hinting - removed old "auto block" to merge buttons in groups (was only in use for radiosity buttons) And went over all warnings. One hooray for make giving clean output :) Well, we need uniform definitions for warnings, so people at least fix them... here's the real bad bugs I found: - in mesh code, a call to editmesh mixed *em and *me - in armature, ED_util.h was not included, so no warnings for wrong call to ED_undo_push() - The extern Py api .h was not included in the bpy_interface.c, showing a several calls using different args. Further just added the missing includes, and removed unused vars.
2009-04-14 15:59:52 +00:00
UI: support searching in menus The basic idea is very simple. Whenever a supported menu is open, one can just start typing and this opens a search that contains all the (nested) menu entries. The main downside is that this collides with accelerator keys. Those are the underlined characters in each menu. For now, we just enable this new searching behavior in a few selected menus: Node Add Menu, View3D Add Menu and Modifier Add Menu. This new functionality can be enabled for a menu by setting `bl_options = {'SEARCH_ON_KEY_PRESS'}` to true in the menu type. The status bar shows `Type to search...` when a menu is opened that supports search. Pull Request: https://projects.blender.org/blender/blender/pulls/110855
2023-09-06 18:16:45 +02:00
void UI_but_flag2_enable(uiBut *but, int flag)
{
but->flag2 |= flag;
}
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
void UI_but_flag_disable(uiBut *but, int flag)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->flag &= ~flag;
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
}
Revert commits to increase button flag bitfield size This reverts the commits 8d9d5da13706b668b9bd0d631e00c9b00b73f3ea, 59cd616534b46ab85b4324a0886bd9eb8876a48b and 98a04ed4524234b1840dc039c2f356db5ac57f26. The commits are causing issues with MSVC, see D14926. I'm working on a different solution, but that will need some work.
2022-05-12 15:53:12 +02:00
bool UI_but_flag_is_set(uiBut *but, int flag)
Driver Keyframing: Some tweaks to make inserting keyframes on Driver F-Curves easier Now, when trying to insert a keyframe on a driven property (using IKEY, or with autokeying enabled), the keyframes will get created on the Driver's F-Curve (instead of creating a new FCurve that goes into the active action, but will never do anything). Furthermore, the x-value of the new keyframe will be the current result of the driver expression. Why/Motivations: This way, it becomes easier to create corrective drivers, as you can position all the targets the driver depends on, then adjust the driver value until it does what you need, and then you keyframe that value to bake it into the Driver F-Curve (in effect, "training" the computer how to behave in that case). Usage Notes: * In practice, that particular workflow is still quite clunky to achieve, due to some quirks of how the driver system and the UI widgets interact. Specifically, you'll need to disable/mute the driver before trying to edit the setting (to prevent the driver from immediately resetting the value - before even autokey fires!). However, if you're using the Graph Editor to preview/monitor/manage the keying process, you'll then want to re-enable the driver before changing the targets, so that you can see how much of a change you'll want to be applying! * The warning about editing driver values may need to be disabled or selectively knocked out. I had it disabled while testing this functionality, but it's actually harmless in its current state (if just a bit annoying).
2016-03-24 19:33:13 +13:00
{
return (but->flag & flag) != 0;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_drawflag_enable(uiBut *but, int flag)
Finish changes in up/down arrows for menus Restored single triangle for special menus, which still isn't perfect but probably makes more sense. Added drawflag bit flags to button, which is currently used to declare, that button need to have up/down arrows. This is needed because it's tricky to distinguish if button should have such arrows. For example, ID search buttons is a simple block button which doesn't directly mean it'll have pop-up menu and not all buttons which cases pop-up menu to display need to have such arrows. So currently only ID selector button is forcing up/down arrows to be displayed, all the rest buttons now behaves in the same way as it used to be before.
2012-05-23 14:24:40 +00:00
{
but->drawflag |= flag;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_drawflag_disable(uiBut *but, int flag)
Finish changes in up/down arrows for menus Restored single triangle for special menus, which still isn't perfect but probably makes more sense. Added drawflag bit flags to button, which is currently used to declare, that button need to have up/down arrows. This is needed because it's tricky to distinguish if button should have such arrows. For example, ID search buttons is a simple block button which doesn't directly mean it'll have pop-up menu and not all buttons which cases pop-up menu to display need to have such arrows. So currently only ID selector button is forcing up/down arrows to be displayed, all the rest buttons now behaves in the same way as it used to be before.
2012-05-23 14:24:40 +00:00
{
but->drawflag &= ~flag;
}
Revert release branch only commit after merge This is a revert of a revert, because the initial revert is only supposed to be in the release branch. This reverts commit 3eed00dc546b5930b255572901915ccbc26c0e69.
2023-02-20 11:51:16 +01:00
void UI_but_dragflag_enable(uiBut *but, int flag)
{
but->dragflag |= flag;
}
void UI_but_dragflag_disable(uiBut *but, int flag)
{
but->dragflag &= ~flag;
}
Cleanup: Add/use function to disable buttons with a disabled hint We do this in a couple of places, so it's worth having the logic wrapped into a function. Also, the only way to set the disabled hint for a button from outside of `interface/` was through `UI_block_lock_set()`/`UI_block_lock_clear()`, for which the usage isn't obvious when you just try to disable a single button.
2020-09-03 17:39:57 +02:00
void UI_but_disable(uiBut *but, const char *disabled_hint)
{
UI_but_flag_enable(but, UI_BUT_DISABLED);
/* Only one disabled hint at a time currently. Don't override the previous one here. */
if (but->disabled_info && but->disabled_info[0]) {
return;
}
but->disabled_info = disabled_hint;
}
UI: Input Placeholders Optional inline hint describing the expected value of an input field. Pull Request: #112104
2023-10-12 11:44:08 -07:00
void UI_but_placeholder_set(uiBut *but, const char *placeholder_text)
{
MEM_SAFE_FREE(but->placeholder);
but->placeholder = BLI_strdup_null(placeholder_text);
}
const char *ui_but_placeholder_get(uiBut *but)
{
const char *placeholder = (but->placeholder) ? but->placeholder : nullptr;
if (!placeholder && but->rnaprop) {
if (but->type == UI_BTYPE_SEARCH_MENU) {
StructRNA *type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
const short idcode = RNA_type_to_ID_code(type);
if (idcode != 0) {
RNA_enum_name(rna_enum_id_type_items, idcode, &placeholder);
placeholder = CTX_IFACE_(BLT_I18NCONTEXT_ID_ID, placeholder);
}
UI: Fix Placeholder Bad String Comparison Bad string comparison in ui_but_placeholder_get() Pull Request: https://projects.blender.org/blender/blender/pulls/113706
2023-10-14 01:42:49 +02:00
else if (type && !STREQ(RNA_struct_identifier(type), "UnknownType")) {
UI: Improved Placeholder Defaults Improvements to how placeholder strings are guessed. Checking for search icon, and also using name of the RNA property type. Pull Request: https://projects.blender.org/blender/blender/pulls/113688
2023-10-13 18:53:33 +02:00
placeholder = RNA_struct_ui_name(type);
UI: Input Placeholders Optional inline hint describing the expected value of an input field. Pull Request: #112104
2023-10-12 11:44:08 -07:00
}
}
UI: Improved Placeholder Defaults Improvements to how placeholder strings are guessed. Checking for search icon, and also using name of the RNA property type. Pull Request: https://projects.blender.org/blender/blender/pulls/113688
2023-10-13 18:53:33 +02:00
else if (but->type == UI_BTYPE_TEXT && but->icon == ICON_VIEWZOOM) {
placeholder = CTX_IFACE_(BLT_I18NCONTEXT_ID_WINDOWMANAGER, "Search");
}
UI: Input Placeholders Optional inline hint describing the expected value of an input field. Pull Request: #112104
2023-10-12 11:44:08 -07:00
}
return placeholder;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_type_set_menu_from_pulldown(uiBut *but)
Own recent removal of string encoded menus missed render layers/passes
2014-02-12 00:08:54 +11:00
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
BLI_assert(but->type == UI_BTYPE_PULLDOWN);
but->type = UI_BTYPE_MENU;
UI_but_drawflag_disable(but, UI_BUT_TEXT_RIGHT);
UI_but_drawflag_enable(but, UI_BUT_TEXT_LEFT);
Own recent removal of string encoded menus missed render layers/passes
2014-02-12 00:08:54 +11:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int UI_but_return_value_get(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
{
return but->retval;
}
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *UI_but_operator_ptr_ensure(uiBut *but)
UI: * Added support for defining properties for operator buttons, with uiButGetOperatorPtrRNA. Needed to cleanup a hack that was there for operator properties in RNA, now a separate OperatorProperties type is used for storing operator properties, instead of being part of the Operator type itself. * Allow selecting menu items with mouse release instead of press again. * Fix some cases with hanging tooltips in the UI.
2008-12-16 20:03:28 +00:00
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->optype && !but->opptr) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
but->opptr = MEM_cnew<PointerRNA>(__func__);
avoid operator type lookups when its known
2009-11-24 16:19:15 +00:00
WM_operator_properties_create_ptr(but->opptr, but->optype);
UI: * Added support for defining properties for operator buttons, with uiButGetOperatorPtrRNA. Needed to cleanup a hack that was there for operator properties in RNA, now a separate OperatorProperties type is used for storing operator properties, instead of being part of the Operator type itself. * Allow selecting menu items with mouse release instead of press again. * Fix some cases with hanging tooltips in the UI.
2008-12-16 20:03:28 +00:00
}
return but->opptr;
}
UI: Support setting context for buttons without layout It was possible to set context pointers for buttons via the layout, but not for buttons in places where the layout system wasn't used (where buttons are placed manually). This is needed for buttons in the Outliner, see D14653.
2022-04-26 22:23:52 +02:00
void UI_but_context_ptr_set(uiBlock *block, uiBut *but, const char *name, const PointerRNA *ptr)
{
Cleanup: Use const for context store variables Generally the context store is owned by `uiBlock`. Other pointers to the store (in `bContext` and other operator data) shouldn't change it, so those variables are now const. One exception is the pointer in `uiLayout`, but that has a clearly short lifetime, so that's okay.
2023-08-31 11:59:58 -04:00
bContextStore *ctx = CTX_store_add(block->contexts, name, ptr);
ctx->used = true;
but->context = ctx;
UI: Support setting context for buttons without layout It was possible to set context pointers for buttons via the layout, but not for buttons in places where the layout system wasn't used (where buttons are placed manually). This is needed for buttons in the Outliner, see D14653.
2022-04-26 22:23:52 +02:00
}
const PointerRNA *UI_but_context_ptr_get(const uiBut *but, const char *name, const StructRNA *type)
{
return CTX_store_ptr_lookup(but->context, name, type);
}
Cleanup: Use const for context store variables Generally the context store is owned by `uiBlock`. Other pointers to the store (in `bContext` and other operator data) shouldn't change it, so those variables are now const. One exception is the pointer in `uiLayout`, but that has a clearly short lifetime, so that's okay.
2023-08-31 11:59:58 -04:00
const bContextStore *UI_but_context_get(const uiBut *but)
Drag & drop: Support using context of hovered button when dropping Buttons can hold context and it's very useful to use this as a way to let buttons provide context for drop operators. For example, with this D13549 can make the material slot list set the material-slot pointer for each row, and the drop operator can just query that.
2022-01-28 16:42:23 +01:00
{
return but->context;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_unit_type_set(uiBut *but, const int unit_type)
bugfix [#25154] .MXF files should be included as a known video file type in the sequencer [#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar. - non rna buttons can now have units set. - calls with invalid units system now raises an assert(). - include .mxf in filter.
2010-12-10 04:10:21 +00:00
{
Cleanup: use function style casts for C++
2022-09-30 14:16:14 +10:00
but->unit_type = uchar(RNA_SUBTYPE_UNIT_VALUE(unit_type));
bugfix [#25154] .MXF files should be included as a known video file type in the sequencer [#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar. - non rna buttons can now have units set. - calls with invalid units system now raises an assert(). - include .mxf in filter.
2010-12-10 04:10:21 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
int UI_but_unit_type_get(const uiBut *but)
bugfix [#25154] .MXF files should be included as a known video file type in the sequencer [#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar. - non rna buttons can now have units set. - calls with invalid units system now raises an assert(). - include .mxf in filter.
2010-12-10 04:10:21 +00:00
{
Cleanup: replace C-style casts with functional casts for numeric types
2022-09-25 18:33:28 +10:00
const int ownUnit = int(but->unit_type);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* own unit define always takes precedence over RNA provided, allowing for overriding
Graph Editor "Active Keyframe" settings This commit makes some tweaks to the way that the "active keyframe" settings in the Properties region in the Graph Editor work (for the better, hopefully). Basically, the problem was that previously, these were clunky and non- intuitive to use, since they were just directly displaying the RNA properties for those keyframes for editing purposes. But due to limitations of RNA (i.e. from a RNA pointer to a keyframe, you couldn't see which F-Curve you came from), several things were impossible, notably: 1) Doing proper updates, including validating that the handles are in a valid state - that requires access to the F-Curve to provide to the F-Curve-based curve validity checking functions 2) Having the values of the keyframes display in whatever unit that the property the F-Curve affects displays as - for this, you once again need to know the F-Curve in order to resolve the property that it affects; also the fact that only a single unit could be set for RNA properties further limited things This commit basically gets around these problems by moving away from a layout-engine based approach to one where we attach custom update callbacks and also override the units of the y-co widgets when creating the widgets for these, thus allowing the buttons to work in the ways that animators expect.
2011-08-06 07:01:07 +00:00
* default value provided in RNA in a few special cases (i.e. Active Keyframe in Graph Edit)
*/
style cleanup
2012-07-07 22:51:57 +00:00
/* XXX: this doesn't allow clearing unit completely, though the same could be said for icons */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if ((ownUnit != 0) || (but->rnaprop == nullptr)) {
Graph Editor "Active Keyframe" settings This commit makes some tweaks to the way that the "active keyframe" settings in the Properties region in the Graph Editor work (for the better, hopefully). Basically, the problem was that previously, these were clunky and non- intuitive to use, since they were just directly displaying the RNA properties for those keyframes for editing purposes. But due to limitations of RNA (i.e. from a RNA pointer to a keyframe, you couldn't see which F-Curve you came from), several things were impossible, notably: 1) Doing proper updates, including validating that the handles are in a valid state - that requires access to the F-Curve to provide to the F-Curve-based curve validity checking functions 2) Having the values of the keyframes display in whatever unit that the property the F-Curve affects displays as - for this, you once again need to know the F-Curve in order to resolve the property that it affects; also the fact that only a single unit could be set for RNA properties further limited things This commit basically gets around these problems by moving away from a layout-engine based approach to one where we attach custom update callbacks and also override the units of the y-co widgets when creating the widgets for these, thus allowing the buttons to work in the ways that animators expect.
2011-08-06 07:01:07 +00:00
return ownUnit << 16;
bugfix [#25154] .MXF files should be included as a known video file type in the sequencer [#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar. - non rna buttons can now have units set. - calls with invalid units system now raises an assert(). - include .mxf in filter.
2010-12-10 04:10:21 +00:00
}
Cleanup: Interface, Clang-Tidy else-after-return fixes This addresses warnings from Clang-Tidy's `readability-else-after-return` rule in the `source/blender/editors/interface` module. No functional changes.
2020-07-03 14:20:10 +02:00
return RNA_SUBTYPE_UNIT(RNA_property_subtype(but->rnaprop));
bugfix [#25154] .MXF files should be included as a known video file type in the sequencer [#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar. - non rna buttons can now have units set. - calls with invalid units system now raises an assert(). - include .mxf in filter.
2010-12-10 04:10:21 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_func_handle_set(uiBlock *block, uiBlockHandleFunc func, void *arg)
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->handle_func = func;
block->handle_func_arg = arg;
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_func_set(uiBlock *block, uiButHandleFunc func, void *arg1, void *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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->func = func;
block->func_arg1 = arg1;
block->func_arg2 = 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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_block_funcN_set(uiBlock *block, uiButHandleNFunc funcN, void *argN, void *arg2)
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
{
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (block->func_argN) {
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
MEM_freeN(block->func_argN);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
Fix: uiBlockSetNFunc was using uiButHandleFunc as param signature, instead of uiButHandleNFunc one (was working because both are the same currently).
2013-04-13 16:28:39 +00:00
block->funcN = funcN;
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->func_argN = argN;
block->func_arg2 = arg2;
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_func_rename_set(uiBut *but, uiButHandleRenameFunc func, void *arg1)
2.5 Further work on new "text search" button. - Now allows to browse items (mouse, arrow key) - Assigns active value - Uses different backdrop to distinguish from popup menus - Cleaned API for it, so it can be used nicely generic Also added a search menu, which shows all currently working operators: CTRL+ALT+F. (mind the looks, it needs some tweaks!) To make a menu activating a button I've added a new event... could use some tweaks. Important note: the callback to pass on "old string" for text button (bone rename) couldn't work yet, added first code for new callback, but has to be worked on further. When bone rename gets added it can be tested.
2009-06-03 18:31:37 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->rename_func = func;
but->rename_arg1 = arg1;
2.5 Further work on new "text search" button. - Now allows to browse items (mouse, arrow key) - Assigns active value - Uses different backdrop to distinguish from popup menus - Cleaned API for it, so it can be used nicely generic Also added a search menu, which shows all currently working operators: CTRL+ALT+F. (mind the looks, it needs some tweaks!) To make a menu activating a button I've added a new event... could use some tweaks. Important note: the callback to pass on "old string" for text button (bone rename) couldn't work yet, added first code for new callback, but has to be worked on further. When bone rename gets added it can be tested.
2009-06-03 18:31:37 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_func_drawextra_set(
uiBlock *block,
void (*func)(const bContext *C, void *idv, void *arg1, void *arg2, rcti *rect),
void *arg1,
void *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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->drawextra = func;
block->drawextra_arg1 = arg1;
block->drawextra_arg2 = 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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_func_set(uiBut *but, uiButHandleFunc func, void *arg1, void *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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func = func;
but->func_arg1 = arg1;
but->func_arg2 = 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
}
UI: Add type-safe C++ button apply function object No user visible changes expected. Rather than relying on a C-style function pointer with void pointer arguments, allow storing a `std::function` object, which can hold arbitrary data in a type safe way. This can be conveniently used with lambdas for example. This is not used yet, but will be with #104831 merged. Replacing the existing C-style callback uses with this can be done separately. Pull Request: https://projects.blender.org/blender/blender/pulls/109016
2023-06-26 16:39:51 +02:00
void UI_but_func_set(uiBut *but, std::function<void(bContext &)> func)
{
but->apply_func = std::move(func);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_funcN_set(uiBut *but, uiButHandleNFunc funcN, void *argN, void *arg2)
2.5: ID datablock button back, previously known as std_libbuttons. The way this worked in 2.4x wasn't really clean, with events going all over the place and using dubious variables such as G.but->lockpoin or G.sima->menunr. It works as follows now, for example: xco= uiDefIDPoinButs(block, CTX_data_main(C), NULL, (ID**)&sima->image, ID_IM, &sima->pin, xco, yco, sima_idpoin_handle, UI_ID_BROWSE|UI_ID_RENAME|UI_ID_ADD_NEW|UI_ID_OPEN|UI_ID_DELETE|UI_ID_ALONE|UI_ID_PIN); The last two parameters are a callback function, and a list of events or functionalities that are supported. The callback function will then get the ID pointer + event to handle.
2009-02-06 16:40:14 +00:00
{
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (but->func_argN) {
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
MEM_freeN(but->func_argN);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->funcN = funcN;
but->func_argN = argN;
but->func_arg2 = arg2;
2.5: ID datablock button back, previously known as std_libbuttons. The way this worked in 2.4x wasn't really clean, with events going all over the place and using dubious variables such as G.but->lockpoin or G.sima->menunr. It works as follows now, for example: xco= uiDefIDPoinButs(block, CTX_data_main(C), NULL, (ID**)&sima->image, ID_IM, &sima->pin, xco, yco, sima_idpoin_handle, UI_ID_BROWSE|UI_ID_RENAME|UI_ID_ADD_NEW|UI_ID_OPEN|UI_ID_DELETE|UI_ID_ALONE|UI_ID_PIN); The last two parameters are a callback function, and a list of events or functionalities that are supported. The callback function will then get the ID pointer + event to handle.
2009-02-06 16:40:14 +00:00
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_func_complete_set(uiBut *but, uiButCompleteFunc func, void *arg)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->autocomplete_func = func;
but->autofunc_arg = arg;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: support cycling callback for non RNA menus
2015-11-16 06:26:25 +11:00
void UI_but_func_menu_step_set(uiBut *but, uiMenuStepFunc func)
{
but->menu_step_func = func;
}
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
void UI_but_func_tooltip_label_set(uiBut *but, std::function<std::string(const uiBut *but)> func)
{
but->tip_label_func = std::move(func);
UI_but_drawflag_enable(but, UI_BUT_HAS_TOOLTIP_LABEL);
}
UI: custom free function improvements This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits: * The caller can pass `null` to indicate that the value should not be freed. * Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible). I added `uiFreeArgFunc` and used it in other places where appropriate. Differential Revision: https://developer.blender.org/D11738
2021-06-30 17:27:54 +02:00
void UI_but_func_tooltip_set(uiBut *but, uiButToolTipFunc func, void *arg, uiFreeArgFunc free_arg)
UI: add optional tip callback to uiBut, and use it for per-item tooltips in UIList. When defined, uiBut->tip_func is called when button's tip is generated. This allows for advanced, dynamic generation of tooltips. For now, only used by UIList, which can now optionaly use a given string property of each item for its tooltip. Thanks to Campbell for the reviews!
2015-02-11 00:06:03 +01:00
{
but->tip_func = func;
UI: custom free function improvements This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits: * The caller can pass `null` to indicate that the value should not be freed. * Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible). I added `uiFreeArgFunc` and used it in other places where appropriate. Differential Revision: https://developer.blender.org/D11738
2021-06-30 17:27:54 +02:00
if (but->tip_arg_free) {
but->tip_arg_free(but->tip_arg);
UI: add optional tip callback to uiBut, and use it for per-item tooltips in UIList. When defined, uiBut->tip_func is called when button's tip is generated. This allows for advanced, dynamic generation of tooltips. For now, only used by UIList, which can now optionaly use a given string property of each item for its tooltip. Thanks to Campbell for the reviews!
2015-02-11 00:06:03 +01:00
}
UI: custom free function improvements This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits: * The caller can pass `null` to indicate that the value should not be freed. * Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible). I added `uiFreeArgFunc` and used it in other places where appropriate. Differential Revision: https://developer.blender.org/D11738
2021-06-30 17:27:54 +02:00
but->tip_arg = arg;
but->tip_arg_free = free_arg;
UI: add optional tip callback to uiBut, and use it for per-item tooltips in UIList. When defined, uiBut->tip_func is called when button's tip is generated. This allows for advanced, dynamic generation of tooltips. For now, only used by UIList, which can now optionaly use a given string property of each item for its tooltip. Thanks to Campbell for the reviews!
2015-02-11 00:06:03 +01:00
}
UI: Custom Tooltips with Optional Images This adds an optional uiBut callback that allows creating a tooltip line-by-line with specified style and color in any order. It also allows adding images as well to create very informative tooltips. Pull Request: https://projects.blender.org/blender/blender/pulls/105905
2023-09-15 21:06:30 +02:00
void UI_but_func_tooltip_custom_set(uiBut *but,
uiButToolTipCustomFunc func,
void *arg,
uiFreeArgFunc free_arg)
{
but->tip_custom_func = func;
if (but->tip_arg_free) {
but->tip_arg_free(but->tip_arg);
}
but->tip_arg = arg;
but->tip_arg_free = free_arg;
}
Cleanup: Use C++ functor for button pushed query callback C-style callbacks often rely on `void` pointer arguments that are unsafe because of the removed type. C++ functors allow passing arbitrary data along the callback, plus convenient features like defining the callback using a lambda. Didn't port the `typedef` because it doesn't add much in this case, just hides the type from the reader who has to look it up first. Note that this function isn't used in the main branch currently.
2023-06-05 12:45:33 +02:00
void UI_but_func_pushed_state_set(uiBut *but, std::function<bool(const uiBut &)> func)
Fix T62016: Outliner visibility icons drag behaviour broken We are mixing bool and fancy 3-in-1 func-set buttons in the outliner. So they would return different pushed state in ui_drag_toggle_but_pushed_state(). We now have a callback function that allows the button to set its own pushed_button_state callback function. Note: This is a bit of overkill since we are planning to change the 3-in-1 outliner buttons. That said, it may be nice to have, since in the future we can mix those buttons for other things. Reviewers: brecht Differential Revision: https://developer.blender.org/D4434
2019-03-01 13:14:16 -03:00
{
but->pushed_state_func = func;
Spreadsheet: Dataset region for spreadsheet editor This patch adds a left aligned sidebar to the spreadsheet editor. This Sidebar can be used to navigate the geometry component types and attribute domains. It also provides a quick overview of domain sizes. It replaces the two dropdowns in the regions header. Next step will be to add the domain cycling shortcut using the CTRL + mouse wheel. Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin), Hans Goudey (HooglyBoogly). Differential Revision: https://developer.blender.org/D11046
2021-06-25 07:57:24 +02:00
ui_but_update(but);
Fix T62016: Outliner visibility icons drag behaviour broken We are mixing bool and fancy 3-in-1 func-set buttons in the outliner. So they would return different pushed state in ui_drag_toggle_but_pushed_state(). We now have a callback function that allows the button to set its own pushed_button_state callback function. Note: This is a bit of overkill since we are planning to change the 3-in-1 outliner buttons. That said, it may be nice to have, since in the future we can mix those buttons for other things. Reviewers: brecht Differential Revision: https://developer.blender.org/D4434
2019-03-01 13:14:16 -03:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefBlockBut(uiBlock *block,
uiBlockCreateFunc func,
void *arg,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(block, UI_BTYPE_BLOCK, 0, str, x, y, width, height, arg, 0.0, 0.0, tip);
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->block_create_func = func;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(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
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefBlockButN(uiBlock *block,
uiBlockCreateFunc func,
void *argN,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
2.5 First version of search-based ID browsing. Now only in use for the top bar screen/scene browse. The python buttons will follow. Also made search button colors match the theme colors from menu back. Todos for browse-search: - "Add new" will disappear, and become a separate icon button in the row of widgets (like X, delete). - Drawing the preview icons in menu - Make search menu dynamic, with configurable number of items? And/or multi-collumn... for now it's static - Search menu should popup with last active ID visible and selected
2009-06-10 11:43:21 +00:00
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = ui_def_but(
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
block, UI_BTYPE_BLOCK, 0, str, x, y, width, height, nullptr, 0.0, 0.0, tip);
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->block_create_func = func;
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (but->func_argN) {
UI * Fix problem with curve mapping / color ramps not updating things like previews propertly. Now it uses the RNA update of the pointer from the material/texture/.. so each of those can define their own update, but still share the RNA struct. * Code for these templates is now in interface_templates.c * Fix exception for "axis" property, now it always shows normal widget with the PROP_DIRECTION subtype. * Remove context from uiBlockLayoutResolve, no longer needed.
2009-09-16 18:47:42 +00:00
MEM_freeN(but->func_argN);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func_argN = argN;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
2.5 First version of search-based ID browsing. Now only in use for the top bar screen/scene browse. The python buttons will follow. Also made search button colors match the theme colors from menu back. Todos for browse-search: - "Add new" will disappear, and become a separate icon button in the row of widgets (like X, delete). - Drawing the preview icons in menu - Make search menu dynamic, with configurable number of items? And/or multi-collumn... for now it's static - Search menu should popup with last active ID visible and selected
2009-06-10 11:43:21 +00:00
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefMenuBut(uiBlock *block,
uiMenuCreateFunc func,
void *arg,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = ui_def_but(
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
block, UI_BTYPE_PULLDOWN, 0, str, x, y, width, height, arg, 0.0, 0.0, tip);
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->menu_create_func = func;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextMenuBut(uiBlock *block,
uiMenuCreateFunc func,
void *arg,
int icon,
Cleanup: Use StringRef arguments for some UI button functions The benefits are O(1) access to the string size, clearer ownership, and easily accessible utility functions. For now, only change functions where the string is clearly non-null. It's not clear in what cases some other functions recieve null strings.
2024-01-31 17:16:25 -05:00
const StringRef str,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = ui_def_but(
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
block, UI_BTYPE_PULLDOWN, 0, str, x, y, width, height, arg, 0.0, 0.0, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
UI: Add extra padding to menus to draw sub-menu triangles in Shortcut strings would be offset to the left to make space for the triangles, breaking the alignment with other shortcut strings. Now this alignment is kept by making menus slightly wider if there's a sub-menu triangle visible, making room for the triangle.
2018-07-06 19:26:12 +02:00
ui_but_submenu_enable(block, but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->menu_create_func = func;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconMenuBut(uiBlock *block,
uiMenuCreateFunc func,
void *arg,
int icon,
int x,
int y,
short width,
short height,
const char *tip)
Fix drawing of MENU buttons with only an icon, was not aligned right and showing unneeded triangles (+ buttons in Boids Brain).
2009-09-28 15:59:09 +00:00
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = ui_def_but(
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
block, UI_BTYPE_PULLDOWN, 0, "", x, y, width, height, arg, 0.0, 0.0, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag &= ~UI_BUT_ICON_LEFT;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->menu_create_func = func;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix drawing of MENU buttons with only an icon, was not aligned right and showing unneeded triangles (+ buttons in Boids Brain).
2009-09-28 15:59:09 +00:00
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconBlockBut(uiBlock *block,
uiBlockCreateFunc func,
void *arg,
int retval,
int icon,
int x,
int y,
short width,
short height,
const char *tip)
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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = ui_def_but(
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
block, UI_BTYPE_BLOCK, retval, "", x, y, width, height, arg, 0.0, 0.0, tip);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->block_create_func = func;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +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
return but;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefSearchBut(uiBlock *block,
void *arg,
int retval,
int icon,
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
int maxncpy,
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int x,
int y,
short width,
short height,
const char *tip)
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
{
UI: Remove uiBut a1 and a2 values Over the last couple years (!) UI buttons have moved to derived classes, meaning we don't need to use the same "a1" and "a2" variables to store different information. At this point, that information is set specifically by internal UI code, or functions like `UI_but_*_set`. These values are only set to their default 0 values now (or -1 in some non-meaningful cases). This commit removes the values from buttons and removes the remaining a1 and a2 arguments from the UI API.
2024-03-01 14:26:45 -05:00
uiBut *but = ui_def_but(
block, UI_BTYPE_SEARCH_MENU, retval, "", x, y, width, height, arg, 0.0, maxncpy, tip);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Expose PreviewImage & custom icons to py API. This commit mainly: * Exposes PreviewImage struct in RNA, including ways for user to set images data. * Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image. * Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system. * Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons. Note that loading image from files' thumbnails is done when needed (deferred loading), not when defining the custom preview/icon. WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level. We do not want our UI to explode under hundreds of different flashy icons! For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons) and the example/templates featured with Blender. Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29). Differential Revision: https://developer.blender.org/D1255
2015-05-11 16:29:12 +02:00
ui_def_but_icon(but, icon, UI_HAS_ICON);
Squashed commit of the following: commit 6f97e194e58aab38d351c796bf7bb6abca33f5f9 Author: Bastien Montagne <montagne29@wanadoo.fr> Date: Wed Nov 20 21:18:20 2013 +0100 Code cleanup: Move some uiBut->flag to uiBut->drawflag, make those flags anonymous enums. Summary: Make some room in but->flag (I did not add another flag, we already have drawflag, which was nearly not used up till now). Note: I’m not sure whether REDALERT (and perhaps even DISABLED?) should not go to but->drawflag as well... Related to D8 Reviewers: brecht Differential Revision: http://developer.blender.org/D22
2013-11-21 14:43:08 +01:00
but->drawflag |= UI_BUT_ICON_LEFT | UI_BUT_TEXT_LEFT;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_update(but);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
return but;
}
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
void UI_but_func_search_set(uiBut *but,
Cleanup: split button search callbacks into their own struct
2020-05-07 23:16:05 +10:00
uiButSearchCreateFn search_create_fn,
uiButSearchUpdateFn search_update_fn,
Fix T60815: drag & drop crash when search menu is opened immediately after. Patch by matc, some further refactoring by me. Differential Revision: https://developer.blender.org/D4250
2019-03-20 19:26:54 +01:00
void *arg,
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
const bool free_arg,
UI: custom free function improvements This changes `UI_but_func_tooltip_set` so that it allows passing a custom free function, which has two benefits: * The caller can pass `null` to indicate that the value should not be freed. * Arbitrary c++ data can be passed to the callback (before the struct had to be trivially destructible). I added `uiFreeArgFunc` and used it in other places where appropriate. Differential Revision: https://developer.blender.org/D11738
2021-06-30 17:27:54 +02:00
uiFreeArgFunc search_arg_free_fn,
Cleanup: callback naming for search button & update doc-strings Callback naming didn't always make it clear which function updated the search contents and the function used to execute the action.
2020-05-08 12:01:35 +10:00
uiButHandleFunc search_exec_fn,
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
void *active)
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
{
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
uiButSearch *search_but = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* needed since callers don't have access to internal functions
* (as an alternative we could expose it) */
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (search_create_fn == nullptr) {
Cleanup: split button search callbacks into their own struct
2020-05-07 23:16:05 +10:00
search_create_fn = ui_searchbox_create_generic;
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (search_but->arg_free_fn != nullptr) {
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
search_but->arg_free_fn(search_but->arg);
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
search_but->arg = nullptr;
Fix T60815: drag & drop crash when search menu is opened immediately after. Patch by matc, some further refactoring by me. Differential Revision: https://developer.blender.org/D4250
2019-03-20 19:26:54 +01:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
search_but->popup_create_fn = search_create_fn;
search_but->items_update_fn = search_update_fn;
search_but->item_active = active;
UI: add menu search functionality to operator search menu This has some advantages over operator search: - Some operators need options set to be usefully accessed. - Shows key bindings to access menus (for actions that don't have key bindings themselves). - Non operator actions such as check-boxes are also shown. - Menu items can control execution context, using invoke or execute where appropriate so we can control how the operator runs. Part of the design task T74157. This can be tested using the 'Experimental' preferences section or selected in the key-map editor.
2020-03-24 11:34:18 +11:00
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
search_but->arg = arg;
search_but->arg_free_fn = search_arg_free_fn;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: callback naming for search button & update doc-strings Callback naming didn't always make it clear which function updated the search contents and the function used to execute the action.
2020-05-08 12:01:35 +10:00
if (search_exec_fn) {
Build: replace Blender specific DEBUG by standard NDEBUG NDEBUG is part of the C standard and disables asserts. Only this will now be used to decide if asserts are enabled. DEBUG was a Blender specific define, that has now been removed. _DEBUG is a Visual Studio define for builds in Debug configuration. Blender defines this for all platforms. This is still used in a few places in the draw code, and in external libraries Bullet and Mantaflow. Pull Request: https://projects.blender.org/blender/blender/pulls/115774
2023-12-04 15:13:06 +01:00
#ifndef NDEBUG
UI: Make uiBut safe for non-trivial construction No user-visible changes expected. Essentially, this makes it possible to use C++ types like `std::function` inside `uiBut`. This has plenty of benefits, for example this should help significantly reducing unsafe `void *` use (since a `std::function` can hold arbitrary data while preserving types). ---- I wanted to use a non-trivially-constructible C++ type (`std::function`) inside `uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore. Rather than writing worse code, allow non-trivial construction for `uiBut`. Member-initializing all members is annoying since there are so many, but rather safe than sorry. As we use more C++ types (e.g. convert callbacks to use `std::function`), this should become less since they initialize properly on default construction. Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate based on size isn't working anymore. Differential Revision: https://developer.blender.org/D17164 Reviewed by: Hans Goudey
2023-02-03 16:12:14 +01:00
if (but->func) {
Cleanup: use '#' prefix for issues instead of 'T' Match the convention from Gitea instead of Phabricator's T for tasks.
2023-02-12 14:37:16 +11:00
/* watch this, can be cause of much confusion, see: #47691 */
Fix T47691: Missing redraw w/ pop-up dialogs Search buttons would overwrite existing callbacks, even when they weren't needed. Causing missing updates for search buttons in pop-ups.
2016-03-07 16:38:22 +11:00
printf("%s: warning, overwriting button callback with search function callback!\n",
__func__);
}
#endif
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
/* Handling will pass the active item as arg2 later, so keep it nullptr here. */
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
if (free_arg) {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
UI_but_funcN_set(but, search_exec_fn, search_but->arg, nullptr);
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
}
else {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
UI_but_func_set(but, search_exec_fn, search_but->arg, nullptr);
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
}
Fix T47691: Missing redraw w/ pop-up dialogs Search buttons would overwrite existing callbacks, even when they weren't needed. Causing missing updates for search buttons in pop-ups.
2016-03-07 16:38:22 +11:00
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
/* search buttons show red-alert if item doesn't exist, not for menus. Don't do this for
* buttons where any result is valid anyway, since any string will be valid anyway. */
if (0 == (but->block->flag & UI_BLOCK_LOOP) && !search_but->results_are_suggestions) {
For all buttons with search-menu option, the button will show a red-alert drawing when input doesn't exist. Will help debugging when messing with uv-layer names, vertex groups, etc. Also closes bugreport #24905
2010-11-29 15:25:06 +00:00
/* skip empty buttons, not all buttons need input, we only show invalid */
Cleanup: Store UI button drawstr with std::string Similar to bff51ae66c9babf1d2337eecd5fa38e0717aac6a
2024-01-22 14:54:44 -05:00
if (!but->drawstr.empty()) {
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
ui_but_search_refresh(search_but);
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
For all buttons with search-menu option, the button will show a red-alert drawing when input doesn't exist. Will help debugging when messing with uv-layer names, vertex groups, etc. Also closes bugreport #24905
2010-11-29 15:25:06 +00:00
}
2.5 Part one of new text button type: SEARCH_MENU This opens a popup showing all matches for a typed string, nice for object names, materials, operators, and so on. Warning: Currently menu doesn't function yet! Only draws choices. As test I've added an operator search button in top bar. It only shows operators that can be used in this context now. Also that is part of the WIP, tomorrow more fun :)
2009-06-02 18:10:06 +00:00
}
UI: support context menu in menu search popup
2020-05-07 23:16:22 +10:00
void UI_but_func_search_set_context_menu(uiBut *but, uiButSearchContextMenuFn context_menu_fn)
{
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
uiButSearch *but_search = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
but_search->item_context_menu_fn = context_menu_fn;
UI: support context menu in menu search popup
2020-05-07 23:16:22 +10:00
}
Cleanup: split search menu separator argument into own function
2020-05-07 23:16:16 +10:00
void UI_but_func_search_set_sep_string(uiBut *but, const char *search_sep_string)
{
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
uiButSearch *but_search = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
but_search->item_sep_string = search_sep_string;
Cleanup: split search menu separator argument into own function
2020-05-07 23:16:16 +10:00
}
UI: show tool-tips in menu search
2020-05-11 18:37:43 +10:00
void UI_but_func_search_set_tooltip(uiBut *but, uiButSearchTooltipFn tooltip_fn)
{
UI Code Quality: Use derived structs for search buttons and decorators The current on-size-fits-all `uiBut` creates quite a mess, where it's hard to reason about which members are free for use, under which conditions they are used and how. `uiBut` also has members that aren't used at times, violating the "don't pay for what you don't use" principle. To address this, we want to move to typed buttons, where `uiBut` is just a base struct and each type extends it as needed. That structures data better and type specific data is only available if it's actually used by a button type. Two trade-offs: * Many casts to the derived type have to be done. * Sometimes we change the button type after it's created. So I had to add logic to reallocate the button for use with the new, possibly derived struct. Ideally that wouldn't be needed, but for now that's what we have. Part of T74432. Differential Revision: https://developer.blender.org/D7610 Reviewed by: Brecht Van Lommel, Campbell Barton
2020-08-07 14:34:11 +02:00
uiButSearch *but_search = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
but_search->item_tooltip_fn = tooltip_fn;
UI: show tool-tips in menu search
2020-05-11 18:37:43 +10:00
}
Nodes: Add node group assets to search menus Currently node group assets are supported, but using them by dragging from the asset browser is cumbersome. This patch adds all node group assets from user asset libraries and the current file libraries to the add node search menu and the link drag search menu. Node groups added through the search will have their "options" hidden, meaning the data-block selector is displayed. This helps keep the UI clean, and the selector shouldn't be necessary anyway. To make that possible, metadata like the node tree type and its inputs and outputs has to be saved in the file. This requires re-saving the files that contain the assets with the patch applied. The node add search operator is moved from Python to C++ to ease development and allow more flexibility. It supports a tooltip that gives the description of assets. Currently the node groups are added with the asset system's existing "Append & Reuse" behavior. It's likely that linking should be possible in the future too, but for now the idea is to use the more foolproof option that doesn't create dependencies between files. Because loading assets can potentially take a long time, the search menu refreshes its items as new assets are loaded. However, changing the search field is necessary to see the update. Differential Revision: https://developer.blender.org/D15568
2022-09-19 11:57:10 -05:00
void UI_but_func_search_set_listen(uiBut *but, uiButSearchListenFn listen_fn)
{
uiButSearch *but_search = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
but_search->listen_fn = listen_fn;
}
UI: Rename search button variable I landed D10527 in rB1a8aee0a7cec accidentally, and the version there was missing a name change discussed in review. This commit just renames the boolean variable controlling the special behavior for attribute search. Original message meant for this change: For geometry nodes we will use search buttons to display a list of attributes available the last time the node tree was executed (D10519). Because this list is just a hint, we need to be able to enter any string, not just strings from the search items. This patch adds a boolean option to string buttons to enable this. The change is quite simple, changes to behavior are only required in two places. The type-specific button struct changes help a lot here. Differential Revision: https://developer.blender.org/D10527
2021-03-02 12:43:27 -06:00
void UI_but_func_search_set_results_are_suggestions(uiBut *but, const bool value)
UI: Expose an "is first search" boolean to search button callbacks Currently when you open an RNA collection search button, like a vertex group selector, the search filter isn't applied until you start typing, in order to display every option at the start. Otherwise they wouldn't be visible, since the search filter would run for the current text. Currently this check happens in one place, but it relies on the `changed` value of `uiBut`. This is fine in the interface directory, but anywhere else it would require exposing `uiBut.changed`, which is probably too low-level to expose. The solution is adding an `is_first` argument to the search callbacks, which is nice for a few reasons: - They work at a higher level of abstraction, meaning they don't have to worry about how exactly to tell if this is the first search. - It makes it easier to do special behavior when the search menu is first opened. - Then, obviously, it makes that state accessible without including `interface_intern.h`. Needed for attribute search: T85658 Differential Revision: https://developer.blender.org/D10528
2021-03-02 11:42:05 -06:00
{
uiButSearch *but_search = (uiButSearch *)but;
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
UI: Rename search button variable I landed D10527 in rB1a8aee0a7cec accidentally, and the version there was missing a name change discussed in review. This commit just renames the boolean variable controlling the special behavior for attribute search. Original message meant for this change: For geometry nodes we will use search buttons to display a list of attributes available the last time the node tree was executed (D10519). Because this list is just a hint, we need to be able to enter any string, not just strings from the search items. This patch adds a boolean option to string buttons to enable this. The change is quite simple, changes to behavior are only required in two places. The type-specific button struct changes help a lot here. Differential Revision: https://developer.blender.org/D10527
2021-03-02 12:43:27 -06:00
but_search->results_are_suggestions = value;
UI: Expose an "is first search" boolean to search button callbacks Currently when you open an RNA collection search button, like a vertex group selector, the search filter isn't applied until you start typing, in order to display every option at the start. Otherwise they wouldn't be visible, since the search filter would run for the current text. Currently this check happens in one place, but it relies on the `changed` value of `uiBut`. This is fine in the interface directory, but anywhere else it would require exposing `uiBut.changed`, which is probably too low-level to expose. The solution is adding an `is_first` argument to the search callbacks, which is nice for a few reasons: - They work at a higher level of abstraction, meaning they don't have to worry about how exactly to tell if this is the first search. - It makes it easier to do special behavior when the search menu is first opened. - Then, obviously, it makes that state accessible without including `interface_intern.h`. Needed for attribute search: T85658 Differential Revision: https://developer.blender.org/D10528
2021-03-02 11:42:05 -06:00
}
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
/* Callbacks for operator search button. */
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
static void operator_enum_search_update_fn(
const bContext *C, void *but, const char *str, uiSearchItems *items, const bool /*is_first*/)
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
{
wmOperatorType *ot = ((uiBut *)but)->optype;
PropertyRNA *prop = ot->prop;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
if (prop == nullptr) {
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
printf("%s: %s has no enum property set\n", __func__, ot->idname);
}
else if (RNA_property_type(prop) != PROP_ENUM) {
printf("%s: %s \"%s\" is not an enum property\n",
__func__,
ot->idname,
RNA_property_identifier(prop));
}
else {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
/* Will create it if needed! */
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *ptr = UI_but_operator_ptr_ensure(static_cast<uiBut *>(but));
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
RNA API: use bool's for enum itemf callbacks.
2014-01-04 18:08:43 +11:00
bool do_free;
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
const EnumPropertyItem *all_items;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
RNA_property_enum_items_gettexted((bContext *)C, ptr, prop, &all_items, nullptr, &do_free);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
UI: show recently selected items at the top of searches The goal is to make the search faster to use by dynamically adapting to the user. This can be achieved using the simple but common approach of showing recently selected items at the top. Note, that the "matching score" between the query and each search item still has precedence when determining the order. So the last used item is only at the top, if there is no other search item that matches the query better. Besides making the search generally faster to use, my hope is that this can also reduce the need for manually weighting search items in some places. This is because while the ordering might not be perfect the first time, it will always be once the user selected the element that should be at the top once. This patch includes: * Support for taking recent searches into account in string searching. * Keep track of a global list of recent searches. * Store recent searches on disk similar to recently opened files. * A new setting in the user preferences that allows disabling the functionality. This can be used if deterministic key strokes are required, e.g. for automated tests. In the future this could be improved in different ways: * Add some kind of separator in the search list to indicate which elements are at the top because they have been used recently. * Store the recent search items per search, instead of in a global list. This way it could adapt to the user even better. Pull Request: https://projects.blender.org/blender/blender/pulls/110828
2023-09-25 10:56:12 +02:00
blender::ui::string_search::StringSearch<const EnumPropertyItem> search;
BLI: refactor string search to use C++ API The API becomes much simpler by using C++. Also, it removes the need for manual memory management. Pull Request: https://projects.blender.org/blender/blender/pulls/110826
2023-08-05 10:54:23 +02:00
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
for (const EnumPropertyItem *item = all_items; item->identifier; item++) {
BLI: refactor string search to use C++ API The API becomes much simpler by using C++. Also, it removes the need for manual memory management. Pull Request: https://projects.blender.org/blender/blender/pulls/110826
2023-08-05 10:54:23 +02:00
search.add(item->name, item);
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
}
Fix T78084: Search does not accept text fragments everywhere This was reported for the "Add Node" search functionality, but is relevant in other searches as well. So e.g. when searching for "Separate XYZ", typing "sep", then " " (with the intention to type "X" next) would clear the search field. Now use the same method (matching against all search words) as in F3 searching ('menu_search_update_fn') in other searches as well [searching IDs, property objects, finding nodes,...] This should give a much nicer search experience in general. Note: this does not touch other searches in the Dopesheet, Outliner, Filebrowser or User Preferences that have other search implementations. Maniphest Tasks: T78084 Differential Revision: https://developer.blender.org/D8232
2020-07-07 10:08:42 +02:00
BLI: refactor string search to use C++ API The API becomes much simpler by using C++. Also, it removes the need for manual memory management. Pull Request: https://projects.blender.org/blender/blender/pulls/110826
2023-08-05 10:54:23 +02:00
const blender::Vector<const EnumPropertyItem *> filtered_items = search.query(str);
for (const EnumPropertyItem *item : filtered_items) {
Cleanup: consistent use of tags: NOTE/TODO/FIXME/XXX Also use doxy style function reference `#` prefix chars when referencing identifiers.
2021-07-03 23:08:40 +10:00
/* NOTE: need to give the index rather than the
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
* identifier because the enum can be freed */
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
if (!UI_search_item_add(items, item->name, POINTER_FROM_INT(item->value), item->icon, 0, 0))
{
break;
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
if (do_free) {
UI: improve search results by using fuzzy and prefix matching Blender does string based searching in many different places. This patch updates four of these places to use the new string search api in `BLI_string_search.h`. In the future we probably want to update the other searches as well. Reviewers: Severin, pablovazquez Differential Revision: https://developer.blender.org/D8825
2020-09-09 13:44:39 +02:00
MEM_freeN((void *)all_items);
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
}
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
}
}
Cleanup: remove redundant struct qualifiers
2023-06-03 08:36:28 +10:00
static void operator_enum_search_exec_fn(bContext * /*C*/, void *but, void *arg2)
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
{
wmOperatorType *ot = ((uiBut *)but)->optype;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
/* Will create it if needed! */
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *opptr = UI_but_operator_ptr_ensure(static_cast<uiBut *>(but));
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
if (ot) {
if (ot->prop) {
BLI_utildefines: rename pointer conversion macros Terms get/set don't make much sense when casting values. Name macros so the conversion is obvious, use common prefix for easier completion. - GET_INT_FROM_POINTER -> POINTER_AS_INT - SET_INT_IN_POINTER -> POINTER_FROM_INT - GET_UINT_FROM_POINTER -> POINTER_AS_UINT - SET_UINT_IN_POINTER -> POINTER_FROM_UINT
2018-09-19 12:05:58 +10:00
RNA_property_enum_set(opptr, ot->prop, POINTER_AS_INT(arg2));
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
/* We do not call op from here, will be called by button code.
Cleanup: correct file names in comments after C -> C++ renaming Use back-tick quotes to differentiate these from plain text.
2023-07-31 11:50:54 +10:00
* ui_apply_but_funcs_after() (in `interface_handlers.cc`)
Cleanup: comment length in interface
2019-04-17 08:44:38 +02:00
* called this func before checking operators,
* because one of its parameters is the button itself! */
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
}
else {
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
printf("%s: op->prop for '%s' is nullptr\n", __func__, ot->idname);
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
}
}
}
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
uiBut *uiDefSearchButO_ptr(uiBlock *block,
wmOperatorType *ot,
IDProperty *properties,
void *arg,
int retval,
int icon,
Cleanup: rename max-length to maxncpy as this includes the null byte
2023-06-10 17:21:24 +10:00
int maxncpy,
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int x,
int y,
short width,
short height,
const char *tip)
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
{
Refactor: UI: Avoid a1 and a1 values for search button preview grid size
2024-02-29 21:49:22 -05:00
uiBut *but = uiDefSearchBut(block, arg, retval, icon, maxncpy, x, y, width, height, tip);
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
UI_but_func_search_set(but,
Fix crash accessing nodes search menu Was caused by d49985c.
2016-03-02 17:57:16 +05:00
ui_searchbox_create_generic,
Cleanup: callback naming for search button & update doc-strings Callback naming didn't always make it clear which function updated the search contents and the function used to execute the action.
2020-05-08 12:01:35 +10:00
operator_enum_search_update_fn,
Fix T60815: drag & drop crash when search menu is opened immediately after. Patch by matc, some further refactoring by me. Differential Revision: https://developer.blender.org/D4250
2019-03-20 19:26:54 +01:00
but,
Geometry Nodes: Add domain and data type to attribute search This patch adds domain and data type information to each row of the attribute search menu. The data type is displayed on the right, just like how the list is exposed for the existing point cloud and hair attribute panels. The domain is exposed on the left like the menu hierarchy from menu search. For the implementation, the attribute hint information is stored as a set instead of a multi-value map so that every item (which we need to point to descretely in the search process) contains the necessary data type and domain information by itself. We also need to allocate a new struct for every button, which requires a change to allow passing a newly allocated argument to search buttons. Note that the search does't yet handle the case where there are two attributes with the same name but different domains or data types in the input geometry set. That will be handled as a separate improvement. Differential Revision: https://developer.blender.org/D10623
2021-04-14 11:11:51 -05:00
false,
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr,
Cleanup: callback naming for search button & update doc-strings Callback naming didn't always make it clear which function updated the search contents and the function used to execute the action.
2020-05-08 12:01:35 +10:00
operator_enum_search_exec_fn,
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
nullptr);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
but->optype = ot;
but->opcontext = WM_OP_EXEC_DEFAULT;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
if (properties) {
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *ptr = UI_but_operator_ptr_ensure(but);
Cleanup: spelling in comments
2022-04-05 07:39:40 +10:00
/* Copy id-properties. */
fix for crash in r56063, was just missing an ID property copy (which menu does)
2013-04-19 12:14:15 +00:00
ptr->data = IDP_CopyProperty(properties);
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Fix: when using a search menu with an operator's enum prop, the operator was previously always executed with default options (appart from the search-set enum, of course). Now we store the op's properties in search button, so that you can specify non-default options (as it was already possible with e.g. pop-up menu from an operator's enum prop). To achieve this, some code (callbacks and search button creation) was moved from wm_operators.c to interface/interface.c, and a new UI function was added, uiDefSearchButO_ptr. Note: This new code uses the fact that uiButHandleFunc callbacks get executed before operator when one of its arg is the button itself! Many thanks to Campbell who helped me a lot with this patch! Cleanup: also removed two unused pointers from uiBut struct.
2013-04-15 15:01:12 +00:00
return but;
}
Spreadsheet: Dataset region for spreadsheet editor This patch adds a left aligned sidebar to the spreadsheet editor. This Sidebar can be used to navigate the geometry component types and attribute domains. It also provides a quick overview of domain sizes. It replaces the two dropdowns in the regions header. Next step will be to add the domain cycling shortcut using the CTRL + mouse wheel. Reviewer: Dalai Felinto (dfelinto), Julian Eisel (Severin), Hans Goudey (HooglyBoogly). Differential Revision: https://developer.blender.org/D11046
2021-06-25 07:57:24 +02:00
void UI_but_hint_drawstr_set(uiBut *but, const char *string)
{
ui_but_add_shortcut(but, string, false);
}
UI: Icon number indicator for data-blocks Adds the possibility of having a little number on top of icons. At the moment this is used for: * Outliner * Node Editor bread-crumb * Node Group node header For the outliner there is almost no functional change. It is mostly a refactor to handle the indicators as part of the icon shader instead of the outliner draw code. (note that this was already recently changed in a5d3b648e3e2). The difference is that now we use rounded border rectangle instead of circles, and we can go up to 999 elements. So for the outliner this shows the number of collapsed elements of a certain type (e.g., mesh objects inside a collapsed collection). For the node editors is being used to show the use count for the data-block. This is important for the node editor, so users know whether the node-group they are editing (or are about to edit) is used elsewhere. This is particularly important when the Node Options are hidden, which is the default for node groups appended from the asset libraries. --- Note: This can be easily enabled for ID templates which can then be part of T84669. It just need to call UI_but_icon_indicator_number_set in the function template_add_button_search_menu. --- Special thanks Clément Foucault for the help figuring out the shader, Julian Eisel for the help navigating the UI code, and Pablo Vazquez for the collaboration in this design solution. For images showing the result check the Differential Revision. Differential Revision: https://developer.blender.org/D16284
2022-10-20 16:37:07 +02:00
void UI_but_icon_indicator_number_set(uiBut *but, const int indicator_number)
{
UI_icon_text_overlay_init_from_count(&but->icon_overlay_text, indicator_number);
}
UI: Outliner "File Mode" Manage User Count In Outliner "Blender File Mode" view, show user counts, and allow removing and adding fake user, requested in #118655. Pull Request: https://projects.blender.org/blender/blender/pulls/118691
2024-04-20 02:50:12 +02:00
void UI_but_icon_indicator_set(uiBut *but, const char *string)
{
STRNCPY(but->icon_overlay_text.text, string);
}
void UI_but_icon_indicator_color_set(uiBut *but, const uchar color[4])
{
copy_v4_v4_uchar(but->icon_overlay_text.color, color);
}
UI: Draw real node sockets for node input buttons For buttons representing node inputs (e.g. in the material properties) rather than drawing some generic socket icon, the actual sockets are drawn now. That includes color, shape and the selection outline. This should make it easier to understand what these buttons relate to. Screenshots: {F8469252}, {F8469248} (The left alignment will be done in a follow-up commit.) Differential Revision: https://developer.blender.org/D7409 Reviewed by: Brecht Van Lommel, Clément Foucault, William Reynish
2020-04-16 15:09:49 +02:00
void UI_but_node_link_set(uiBut *but, bNodeSocket *socket, const float draw_color[4])
{
but->flag |= UI_BUT_NODE_LINK;
but->custom_data = socket;
rgba_float_to_uchar(but->col, draw_color);
}
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
void UI_but_number_step_size_set(uiBut *but, float step_size)
{
uiButNumber *but_number = (uiButNumber *)but;
BLI_assert(but->type == UI_BTYPE_NUM);
but_number->step_size = step_size;
BLI_assert(step_size > 0);
}
void UI_but_number_precision_set(uiBut *but, float precision)
{
uiButNumber *but_number = (uiButNumber *)but;
BLI_assert(but->type == UI_BTYPE_NUM);
but_number->precision = precision;
Fix T80613: Assert in UI_but_number_precision_set -1 is a valid value to pass as RNA float precision. We let the UI code figure out an appropriate precision then. So don't fail the assert if -1 is passed.
2020-09-09 12:06:11 +02:00
/* -1 is a valid value, UI code figures out an appropriate precision then. */
BLI_assert(precision > -2);
UI Code Quality: Use derived struct for number buttons For the man rationale behind this design, see 49f088e2d093. Further, this removes users of uiBut.a1/uiBut.a2, which is a very ugly design choice (hard to reason about). Note that I had to do rather ugly, specific exceptions for the number buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed, this special handling shouldn't be needed anymore. I also had to move a sanity check out of the button definition. It's now moved into a new debug only sanity checking function executed when finishing the layout definition (block end).
2020-09-04 21:18:45 +02:00
}
Refactor: UI: Use derived struct for number slider buttons Similar to d204830107ef7f6f5802. This is the last real use of the a1 and a2 arguments for many button definition functions.
2024-02-01 12:42:25 -05:00
void UI_but_number_slider_step_size_set(uiBut *but, float step_size)
{
uiButNumberSlider *but_number = (uiButNumberSlider *)but;
BLI_assert(but->type == UI_BTYPE_NUM_SLIDER);
but_number->step_size = step_size;
BLI_assert(step_size > 0);
}
void UI_but_number_slider_precision_set(uiBut *but, float precision)
{
uiButNumberSlider *but_number = (uiButNumberSlider *)but;
BLI_assert(but->type == UI_BTYPE_NUM_SLIDER);
but_number->precision = precision;
/* -1 is a valid value, UI code figures out an appropriate precision then. */
BLI_assert(precision > -2);
}
Cleanup: UI: Use derived struct for label buttons, remove a1, a2 usage
2024-03-01 13:46:06 -05:00
void UI_but_label_alpha_factor_set(uiBut *but, const float alpha_factor)
{
uiButLabel *but_label = reinterpret_cast<uiButLabel *>(but);
BLI_assert(but->type == UI_BTYPE_LABEL);
but_label->alpha_factor = alpha_factor;
}
Refactor: UI: Avoid a1 and a1 values for search button preview grid size
2024-02-29 21:49:22 -05:00
void UI_but_search_preview_grid_size_set(uiBut *but, int rows, int cols)
{
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU);
uiButSearch *but_search = reinterpret_cast<uiButSearch *>(but);
but_search->preview_rows = rows;
but_search->preview_cols = cols;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
void UI_but_focus_on_enter_event(wmWindow *win, uiBut *but)
UI Tweaks: Text field in Rename Markers popup now gets focus when the popup appears, saving an extra click I've separated out the "XXX"-'d event-adding-hack section from the search-menu code into a separate API function (as recommended there). This call is used to make sure that textboxes in popups can get activated by default, to allow typing immediately.
2011-02-15 01:24:12 +00:00
{
wmEvent event;
add api call for initializing events from the windows eventstate.
2013-07-29 08:29:04 +00:00
wm_event_init_from_window(win, &event);
style cleanup: interface
2012-03-30 01:51:25 +00:00
event.type = EVT_BUT_OPEN;
event.val = KM_PRESS;
Cleanup: Move interface.c to C++ This is similar to 4537eb0c3b1678a62
2022-04-04 10:24:14 -05:00
event.flag = static_cast<eWM_EventFlag>(0);
style cleanup: interface
2012-03-30 01:51:25 +00:00
event.customdata = but;
Cleanup: use underscore separators for event struct members Improve readability using underscores for separators, e.g. prev_click_time instead of prevclicktime.
2021-10-21 13:24:17 +11:00
event.customdata_free = false;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI Tweaks: Text field in Rename Markers popup now gets focus when the popup appears, saving an extra click I've separated out the "XXX"-'d event-adding-hack section from the search-menu code into a separate API function (as recommended there). This call is used to make sure that textboxes in popups can get activated by default, to allow typing immediately.
2011-02-15 01:24:12 +00:00
wm_event_add(win, &event);
}
UI: Add UILayout.operator_menu_hold This is an operator button that opens a menu when the button is held.
2017-11-02 04:30:07 +11:00
void UI_but_func_hold_set(uiBut *but, uiButHandleHoldFunc func, void *argN)
{
but->hold_func = func;
but->hold_argN = argN;
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::optional<EnumPropertyItem> UI_but_rna_enum_item_get(bContext &C, uiBut &but)
{
PointerRNA *ptr = nullptr;
PropertyRNA *prop = nullptr;
int value = 0;
if (but.rnaprop && RNA_property_type(but.rnaprop) == PROP_ENUM) {
ptr = &but.rnapoin;
prop = but.rnaprop;
value = ELEM(but.type, UI_BTYPE_ROW, UI_BTYPE_TAB) ? int(but.hardmax) :
int(ui_but_value_get(&but));
}
else if (but.optype) {
wmOperatorType *ot = but.optype;
/* So the context is passed to `itemf` functions. */
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *opptr = UI_but_operator_ptr_ensure(&but);
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
WM_operator_properties_sanitize(opptr, false);
/* If the default property of the operator is an enum and is set, fetch the tooltip of the
* selected value so that "Snap" and "Mirror" operator menus in the Animation Editors will
* show tooltips for the different operations instead of the meaningless generic tooltip. */
if (ot->prop && RNA_property_type(ot->prop) == PROP_ENUM) {
if (RNA_struct_contains_property(opptr, ot->prop)) {
ptr = opptr;
prop = ot->prop;
value = RNA_property_enum_get(opptr, ot->prop);
}
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
if (!ptr || !prop) {
return std::nullopt;
}
Fix #103269: node group asset description not showing as tooltip in the Add menu Pull Request #104968
2023-02-22 17:33:04 +01:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
EnumPropertyItem item;
if (!RNA_property_enum_item_from_value_gettexted(&C, ptr, prop, value, &item)) {
return std::nullopt;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
return item;
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_rna_property_identifier(const uiBut &but)
{
if (!but.rnaprop) {
return {};
}
return RNA_property_identifier(but.rnaprop);
}
UI: Refactor quick label tooltip implementation for buttons No user visible changes expected. Used in the asset shelf branch, see #104831. These tooltips only show a label string and appear after a shorter timeout than the regular tooltips. After the regular tooltip timeout they expand to the full tooltip. The toolbar and properties editor navigation tabs make use of this already. The changes here enable more control over quick label tooltips, making them usable in more cases, and less ad-hoc. Main changes: - Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag can be used to enable quick label tooltips. This decentralizes logic in a way that's more consistent and extensible. - Custom callback to return a quick label. This is useful when a label tooltip should be displayed even when there is no button string set. E.g. in the asset shelf with "Show Names" disabled. Pull Request: https://projects.blender.org/blender/blender/pulls/110200
2023-07-25 16:22:31 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_rna_struct_identifier(const uiBut &but)
{
if (but.rnaprop && but.rnapoin.data) {
return RNA_struct_identifier(but.rnapoin.type);
}
if (but.optype) {
return but.optype->idname;
}
if (ELEM(but.type, UI_BTYPE_MENU, UI_BTYPE_PULLDOWN)) {
if (MenuType *mt = UI_but_menutype_get(&but)) {
return mt->idname;
Code cleanup: remove more string encoded menu functions
2014-02-15 11:35:40 +11:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
if (but.type == UI_BTYPE_POPOVER) {
if (PanelType *pt = UI_but_paneltype_get(&but)) {
return pt->idname;
Cleanup: use braces for interface code
2019-03-25 10:15:20 +11:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
return {};
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_label(uiBut &but)
{
if (!but.str.empty()) {
size_t str_len = but.str.size();
if (but.flag & UI_BUT_HAS_SEP_CHAR) {
const size_t sep_index = but.str.find_first_of(UI_SEP_CHAR);
if (sep_index != std::string::npos) {
str_len = sep_index;
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
}
UI: show panel type in Python tooltips Handy when editing UI scripts.
2018-12-19 21:49:04 +11:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
return but.str.substr(0, str_len);
}
return UI_but_string_get_rna_label(but);
}
UI: add popover access for button labels Needed for tool-tips to access labels.
2019-06-19 11:34:54 +10:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_tooltip_label(const uiBut &but)
{
if (!but.tip_label_func) {
return {};
}
return but.tip_label_func(&but);
}
UI: simplify tool-tip logic for operators - Use WM_operatortype_description to get the operator description. - Pass properties to WM_operatortype_name, so the operator name callback is used. - Add UI_but_operatortype_get_from_enum_menu function to access the operator from enum menus. - Change WM_operatortype_description to return NULL when there is no description, use WM_operatortype_description_or_name when either can be used.
2020-09-02 12:54:06 +10:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_rna_label(uiBut &but)
{
if (but.rnaprop) {
return RNA_property_ui_name(but.rnaprop);
}
if (but.optype) {
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *opptr = UI_but_operator_ptr_ensure(&but);
Cleanup: remove redundant std::string / c_str conversion
2024-03-28 12:23:46 +11:00
return WM_operatortype_name(but.optype, opptr);
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
if (ELEM(but.type, UI_BTYPE_MENU, UI_BTYPE_PULLDOWN, UI_BTYPE_POPOVER)) {
if (MenuType *mt = UI_but_menutype_get(&but)) {
return CTX_TIP_(mt->translation_context, mt->label);
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
if (wmOperatorType *ot = UI_but_operatortype_get_from_enum_menu(&but, nullptr)) {
Cleanup: remove redundant std::string / c_str conversion
2024-03-28 12:23:46 +11:00
return WM_operatortype_name(ot, nullptr);
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
if (PanelType *pt = UI_but_paneltype_get(&but)) {
return CTX_TIP_(pt->translation_context, pt->label);
}
}
return {};
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_rna_label_context(const uiBut &but)
{
if (but.rnaprop) {
return RNA_property_translation_context(but.rnaprop);
}
if (but.optype) {
return RNA_struct_translation_context(but.optype->srna);
}
if (ELEM(but.type, UI_BTYPE_MENU, UI_BTYPE_PULLDOWN)) {
if (MenuType *mt = UI_but_menutype_get(&but)) {
return RNA_struct_translation_context(mt->rna_ext.srna);
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
return BLT_I18NCONTEXT_DEFAULT_BPYRNA;
}
std::string UI_but_string_get_tooltip(bContext &C, uiBut &but)
{
if (but.tip_func) {
return but.tip_func(&C, but.tip_arg, but.tip);
}
if (but.tip && but.tip[0]) {
return but.tip;
}
return UI_but_string_get_rna_tooltip(C, but);
}
std::string UI_but_string_get_rna_tooltip(bContext &C, uiBut &but)
{
if (but.rnaprop) {
const char *t = RNA_property_ui_description(but.rnaprop);
if (t && t[0]) {
return t;
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
else if (but.optype) {
Cleanup: Rename function to ensure button operator properties For some reason the "get" function actually allocates the button's operator properties container. This may or may not make sense to do, but while it happens, the function name might as well make that clear.
2024-01-29 10:19:05 -05:00
PointerRNA *opptr = UI_but_operator_ptr_ensure(&but);
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
const bContextStore *previous_ctx = CTX_store_get(&C);
CTX_store_set(&C, but.context);
std::string tmp = WM_operatortype_description(&C, but.optype, opptr).c_str();
CTX_store_set(&C, previous_ctx);
return tmp;
}
if (ELEM(but.type, UI_BTYPE_MENU, UI_BTYPE_PULLDOWN, UI_BTYPE_POPOVER)) {
if (MenuType *mt = UI_but_menutype_get(&but)) {
/* Not all menus are from Python. */
if (mt->rna_ext.srna) {
const char *t = RNA_struct_ui_description(mt->rna_ext.srna);
if (t && t[0]) {
return t;
}
Bugfix [35841] WM_OT_context_[toggle/cycle/etc.] operators dont show shortcut keys in menus (or tooltips) for properties they are used to toggle/cycle through Some properties can be toggled using hotkeys via WM_OT_context_* operators, but these hotkeys aren't really shown anywhere obvious like other hotkeys (i.e. they're not shown in tooltips or menus). Although it is possible to look these up in the userprefs/keymaps editor, it is quite tricky doing so, and most users would just assume that since no shortcut is displayed, there simply isn't one at all. This commit introduces a slightly hacky fix which basically amounts to checking if a property can be set by any of the few operators which are used for this purpose. In order to keep this from being too sluggish, I've currently limited this to only working on Editor (e.g. "Show Seconds" in Anim Editors) and ToolSettings (e.g. "Use Proportional Edit") properties. There are still some corner cases that would be nice to solve too (i.e. the Pivot Type enum menu/dropdown should really be able to show the hotkeys which have been assigned for each of those items, since they're by-and-large quite hidden and obscure), though being able to show some of these is perhaps better than not showing any!
2013-07-07 12:53:15 +00:00
}
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
if (wmOperatorType *ot = UI_but_operatortype_get_from_enum_menu(&but, nullptr)) {
Cleanup: remove redundant std::string / c_str conversion
2024-03-28 12:23:46 +11:00
return WM_operatortype_description(&C, ot, nullptr);
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
}
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
return {};
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
}
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_operator_keymap(bContext &C, uiBut &but)
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
{
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return ui_but_event_operator_string(&C, &but).value_or("");
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_string_get_property_keymap(bContext &C, uiBut &but)
{
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return ui_but_event_property_operator_string(&C, &but).value_or("");
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
}
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_extra_icon_string_get_label(const uiButExtraOpIcon &extra_icon)
{
wmOperatorType *optype = UI_but_extra_operator_icon_optype_get(&extra_icon);
PointerRNA *opptr = UI_but_extra_operator_icon_opptr_get(&extra_icon);
return WM_operatortype_name(optype, opptr);
}
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_extra_icon_string_get_tooltip(bContext &C, const uiButExtraOpIcon &extra_icon)
{
wmOperatorType *optype = UI_but_extra_operator_icon_optype_get(&extra_icon);
PointerRNA *opptr = UI_but_extra_operator_icon_opptr_get(&extra_icon);
return WM_operatortype_description(&C, optype, opptr);
}
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +02:00
Cleanup: Replace UI button "string info" function Instead of a single function with variadic arguments, a special enum type containing which string to request, and a special struct to contain the request and the result, just use separate functions for each request, and return a std::string by value. Also change the enum item string access to just give access to the enum item itself and add const in a few places as necessary. The callers of the API function get much clearer this way, and it's much easier to see which information is used to create certain tooltip strings.
2024-01-18 23:12:09 -05:00
std::string UI_but_extra_icon_string_get_operator_keymap(const bContext &C,
const uiButExtraOpIcon &extra_icon)
{
Refactor: Use std::string for keymap string return values The main simplification is using return values rather than return arguments, and the additional semantic clarity from std::optional. Also use `fmt` for formatting and use lambdas instead of macros as helpers in a few modal keymap formatting functions. Similar commits: - a1792e98a444d004dc4b8f1dd63f62440589387a - f04bc75f8ce0dbef36f440ff3f840c54de9fda12 - 6abf43cef52a3186642959270bfbabe1ea3dc5f3 - 7ca4dcac5a113db514faf7362b95bfe584e252be Pull Request: https://projects.blender.org/blender/blender/pulls/117785
2024-02-07 14:22:54 +01:00
return ui_but_extra_icon_event_operator_string(&C, &extra_icon).value_or("");
UI: Support tooltips for superimposed icons In a couple of places in the UI, we show superimposed icons on buttons to execute an operation (called "Extra Icons" internally). Hovering them would show the tooltip of the underlying button, which is misleading and confusing. There are cases where it's not obvious what an icon does, so a tooltip would be quite useful here. It's likely we are going to use superimposed icons in more places in the future, e.g. see D11890. The extra icon basically acts as an override for the button in the tooltip code. Differential Revision: https://developer.blender.org/D11894 Reviewed by: Campbell Barton
2021-10-08 14:17:03 +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
/* Program Init/Exit */
Cleanup: remove redundant (void) for functions with no args in C++
2023-07-02 19:37:22 +10:00
void UI_init()
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
{
ui_resources_init();
}
Cleanup: remove redundant (void) for functions with no args in C++
2023-07-02 19:37:22 +10:00
void UI_init_userdef()
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
{
Cleanup: run UserDef versioning from readfile.c Now versioning UserDef is run in readfile.c, as is done for other Blender data. Previously versioning was mixed with other run-time initialization, so it needed to be called later by the window manager.
2020-10-02 23:23:57 +10:00
/* Initialize UI variables from values set in the preferences. */
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
uiStyleInit();
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
}
Cleanup: remove redundant (void) for functions with no args in C++
2023-07-02 19:37:22 +10:00
void UI_reinit_font()
Translation: reload font on enabling/disabling use international fonts.
2011-09-21 15:15:30 +00:00
{
uiStyleInit();
}
Cleanup: remove redundant (void) for functions with no args in C++
2023-07-02 19:37:22 +10:00
void UI_exit()
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
ui_resources_free();
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ui_but_clipboard_free();
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
}
Fix T58683: Reload Scripts breaks toolbar button formatting Add a function which clears internal cached operator pointers, run before reloading scripts.
2019-10-01 01:59:31 +10:00
Cleanup: remove redundant (void) for functions with no args in C++
2023-07-02 19:37:22 +10:00
void UI_interface_tag_script_reload()
Fix T58683: Reload Scripts breaks toolbar button formatting Add a function which clears internal cached operator pointers, run before reloading scripts.
2019-10-01 01:59:31 +10:00
{
ui_interface_tag_script_reload_queries();
}
Reference in New Issue Copy Permalink