archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
a1addc5c633d4c35eeb491c698052ec9300271dc
blender-archive/source/blender/editors/interface/interface.c

5079 lines
144 KiB
C
Raw Normal View History

doxygen: prevent GPL license block from being parsed as doxygen comment.
2011-02-23 10:52:22 +00:00
/*
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*/
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
*/
RNA * Rename cname to identifier. * Rename PropertyEnumItem to EnumPropertyItem. * Wrapped min/max/step/precision, pointer type for RNA. * Draw FLT_MAX a bit better in buttons.
2008-11-14 18:46:57 +00:00
#include <float.h>
Fix #20831: setting shadowbuffersize to 10240 only possible via typing it in.
2010-01-26 17:14:13 +00:00
#include <limits.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 <math.h>
#include <string.h>
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
#include <ctype.h>
fix for building on msvc2008 (also style cleanup)
2012-09-04 01:23:50 +00:00
#include <stddef.h> /* offsetof() */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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"
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
#include "DNA_workspace_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
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
#include "BLI_math.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"
#include "BLI_string.h"
#include "BLI_string_utf8.h"
#include "BLI_rect.h"
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
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
#include "BKE_animsys.h"
2.5 Context API This adds the context API as described here. The main practical change now is that C is not longer directly accessible but has to be accessed through accessor functions. This basically adds the implementation of the API and adaption of existing code with some minor changes. The next task of course is to actually use this design to cleanup of bad level calls and global access, in blenkernel, blenloader. http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Context Error, Warning and Debug Info Reporting This adds the error reporting API as described here. It should help clean up error() calls in non-ui code, but eventually can become used for gathering messages for a console window, and throwing exceptions in python scripts when an error happens executing something. http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Reports
2008-12-18 02:56:48 +00:00
#include "BKE_context.h"
Cleanup: getting rid of G.main. Sometimes one needs a *lot* of changes for a single G.main... :/
2018-06-08 12:16:37 +02:00
#include "BKE_idprop.h"
#include "BKE_main.h"
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
#include "BKE_scene.h"
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
#include "BKE_screen.h"
Cleanup: getting rid of G.main. Sometimes one needs a *lot* of changes for a single G.main... :/
2018-06-08 12:16:37 +02:00
#include "BKE_unit.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
Cleanup: move gawain header out of GPU_matrix Avoids requiring glew headers in Python API.
2017-08-21 01:39:03 +10:00
#include "GPU_glew.h"
OpenGL: convert to new matrix API (part 4) Part of T49450, fixes a Push/Pop mismatch from part yesterday's 3.
2017-03-21 16:08:14 -04:00
#include "GPU_matrix.h"
GLRefactor: partially remove gl calls from source/blender/editors. This translates the gl calls to the new GPU_ wrappers from D3501. Given it's tedious and repetitive work, this patch does as much as it can with search + replace, the remainder of the gl calls will need to be manually dealt with on a case by case basis. This fixes 13 of the 28 failing editors when building without opengl. For the list of substitutions see D3502 Reviewers: brecht Differential Revision: https://developer.blender.org/D3502
2018-06-27 19:07:23 -06:00
#include "GPU_state.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
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
#include "BLF_api.h"
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
#include "BLT_translation.h"
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 "UI_interface.h"
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
#include "UI_interface_icons.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
image button was hard coded to draw the splash screen which it loaded from PNG data on every draw. now pass the ImBuf when callign the image button so we could have different images in buttons later on.
2011-09-17 16:57:37 +00:00
#include "IMB_imbuf.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 "WM_api.h"
#include "WM_types.h"
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
#include "WM_message.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 "RNA_access.h"
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
#include "BPY_extern.h"
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
#include "ED_screen.h"
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
#include "ED_numinput.h"
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
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
#include "IMB_colormanagement.h"
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
#include "DEG_depsgraph_query.h"
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
#include "interface_intern.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
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. */
static void ui_but_to_pixelrect(struct rcti *rect, const struct ARegion *ar, struct uiBlock *block, struct uiBut *but);
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
static void ui_def_but_rna__menu(bContext *UNUSED(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
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
#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
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_ex(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
{
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 ************** */
void ui_block_to_window_fl(const ARegion *ar, uiBlock *block, float *x, float *y)
{
float gx, gy;
int sx, sy, getsizex, getsizey;
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
getsizex = BLI_rcti_size_x(&ar->winrct) + 1;
getsizey = BLI_rcti_size_y(&ar->winrct) + 1;
style cleanup: interface
2012-03-30 01:51:25 +00:00
sx = ar->winrct.xmin;
sy = ar->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
style cleanup: interface
2012-03-30 01:51:25 +00:00
gx = *x;
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;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
*x = ((float)sx) + ((float)getsizex) * (0.5f + 0.5f * (gx * block->winmat[0][0] + gy * block->winmat[1][0] + block->winmat[3][0]));
*y = ((float)sy) + ((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
}
void ui_block_to_window(const ARegion *ar, uiBlock *block, int *x, int *y)
{
float fx, fy;
style cleanup: interface
2012-03-30 01:51:25 +00:00
fx = *x;
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
ui_block_to_window_fl(ar, block, &fx, &fy);
style cleanup: interface
2012-03-30 01:51:25 +00:00
*x = (int)(fx + 0.5f);
*y = (int)(fy + 0.5f);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
void ui_block_to_window_rctf(const ARegion *ar, uiBlock *block, 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;
ui_block_to_window_fl(ar, block, &rct_dst->xmin, &rct_dst->ymin);
ui_block_to_window_fl(ar, 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
}
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
float ui_block_to_window_scale(const ARegion *ar, uiBlock *block)
{
/* We could have function for this to avoid dummy arg. */
float dummy_x;
float min_y = 0, max_y = 1;
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;
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
ui_block_to_window_fl(ar, 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;
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
ui_block_to_window_fl(ar, block, &dummy_x, &max_y);
return max_y - min_y;
}
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* for mouse cursor */
void ui_window_to_block_fl(const ARegion *ar, 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
{
float a, b, c, d, e, f, px, py;
int sx, sy, getsizex, getsizey;
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
getsizex = BLI_rcti_size_x(&ar->winrct) + 1;
getsizey = BLI_rcti_size_y(&ar->winrct) + 1;
style cleanup: interface
2012-03-30 01:51:25 +00:00
sx = ar->winrct.xmin;
sy = ar->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
style cleanup: interface
2012-03-30 01:51:25 +00:00
a = 0.5f * ((float)getsizex) * block->winmat[0][0];
b = 0.5f * ((float)getsizex) * block->winmat[1][0];
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
d = 0.5f * ((float)getsizey) * block->winmat[0][1];
e = 0.5f * ((float)getsizey) * block->winmat[1][1];
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
px = *x - sx;
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
style cleanup: interface
2012-03-30 01:51:25 +00: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) {
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
*x -= block->panel->ofsx;
*y -= block->panel->ofsy;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
void ui_window_to_block(const ARegion *ar, uiBlock *block, int *x, int *y)
{
float fx, fy;
style cleanup: interface
2012-03-30 01:51:25 +00:00
fx = *x;
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
ui_window_to_block_fl(ar, block, &fx, &fy);
style cleanup: interface
2012-03-30 01:51:25 +00:00
*x = (int)(fx + 0.5f);
*y = (int)(fy + 0.5f);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
* make function to map mouse into region coords
2008-12-03 20:57:23 +00:00
void ui_window_to_region(const ARegion *ar, int *x, int *y)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
*x -= ar->winrct.xmin;
*y -= ar->winrct.ymin;
* make function to map mouse into region coords
2008-12-03 20:57:23 +00:00
}
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
void ui_region_to_window(const ARegion *ar, int *x, int *y)
{
*x += ar->winrct.xmin;
*y += ar->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
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;
for (uiBut *but = block->buttons.first; but; but = but->next) {
if (but->type == UI_BTYPE_SEPR_SPACER) {
sepr_flex_len++;
}
}
if (sepr_flex_len == 0) {
return;
}
rcti rect;
ui_but_to_pixelrect(&rect, region, block, block->buttons.last);
Fix flexible spacer distance Introduced on 0bce173bc7e9bb6d6cac.
2018-06-13 15:17:56 +02:00
const float buttons_width = (float)rect.xmax + UI_HEADER_OFFSET;
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
const float region_width = (float)region->sizex * U.dpi_fac;
if (region_width <= buttons_width) {
return;
}
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 */
int *spacers_pos = alloca(sizeof(*spacers_pos) * (size_t)sepr_flex_len);
int i = 0;
for (uiBut *but = block->buttons.first; but; but = but->next) {
if (but->type == UI_BTYPE_SEPR_SPACER) {
ui_but_to_pixelrect(&rect, region, block, but);
spacers_pos[i] = rect.xmax + UI_HEADER_OFFSET;
i++;
}
}
const float segment_width = region_width / (float)sepr_flex_len;
float offset = 0, remaining_space = region_width - buttons_width;
i = 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
for (uiBut *but = block->buttons.first; but; but = but->next) {
BLI_rctf_translate(&but->rect, offset, 0);
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);
int segment_end = segment_width * (i + 1);
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
int spacer_end = segment_end - overlap;
int spacer_sta = spacers_pos[i] + offset;
if (spacer_end > spacer_sta) {
float step = min_ff(remaining_space, spacer_end - spacer_sta);
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 {
/* No subwindow created yet, for menus for example, so we use the main
* window instead, since buttons are created there anyway. */
int width = WM_window_pixels_x(window);
int height = WM_window_pixels_y(window);
rcti winrct = {0, width - 1, 0, height - 1};
wmGetProjectionMatrix(block->winmat, &winrct);
block->aspect = 2.0f / fabsf(width * block->winmat[0][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
/**
* Popups will add a margin to #ARegion.winrct for shadow,
* for interactivity (point-inside tests for eg), we want the winrct without the margin added.
*/
void ui_region_winrct_get_no_margin(const struct ARegion *ar, struct rcti *r_rect)
{
uiBlock *block = ar->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);
BLI_rcti_translate(r_rect, ar->winrct.xmin, ar->winrct.ymin);
}
else {
*r_rect = ar->winrct;
}
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
{
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
uiBut *but;
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
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
for (but = block->buttons.first; but; but = but->next) {
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 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
{
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();
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
uiBut *bt, *init_col_bt, *col_bt;
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
for (init_col_bt = bt = block->buttons.first; bt; bt = bt->next) {
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)) {
Blender Font (BLF): add length argument to string width/height functions This also fixes a crash editing buttons longer then UI_MAX_DRAW_STR
2013-12-02 20:33:45 +11:00
j = BLF_width(style->widget.uifont_id, bt->drawstr, sizeof(bt->drawstr));
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
if (j > i)
i = j;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
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
if (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) {
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
{
uiBut *bt;
int xof;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02: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
}
}
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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
for (bt = block->buttons.first; bt; bt = bt->next) {
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = block->buttons.first;
Cleanup: strcmp/strncmp -> STREQ/STREQLEN (in boolean usage). Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)' and 'strcmp(foo, bar) == 0' in several places...
2015-01-26 16:03:11 +01:00
if (bt && STREQLEN(bt->str, "ERROR", 5)) xof = 10;
style cleanup: interface
2012-03-30 01:51:25 +00:00
else xof = 40;
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
{
int xmax, ymax;
int startx, starty;
int width, height;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
better not process events early, could cause troubles later. added a function - wm_window_get_size_ghost(), which looks into the ghost window directly so events dont need processing first.
2009-11-30 14:10:46 +00:00
/* note: this is used for the splash where window bounds event has not been
* updated by ghost, get the window bounds from ghost directly */
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
xmax = WM_window_pixels_x(window);
ymax = WM_window_pixels_y(window);
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
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
width = BLI_rctf_size_x(&block->rect);
height = BLI_rctf_size_y(&block->rect);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
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
startx = (xmax * 0.5f) - (width * 0.5f);
starty = (ymax * 0.5f) - (height * 0.5f);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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, startx - block->rect.xmin, starty - block->rect.ymin);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
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
/* 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);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
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] = {
block->pie_data.pie_center_spawned[0],
Cleanup: trailing commas Needed for clan-format not to wrap onto one line.
2019-02-03 14:01:45 +11:00
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(
wmWindow *window, uiBlock *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
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
{
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
int width, height, oldwidth, oldheight;
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
int oldbounds, xmax, ymax, raw_x, raw_y;
fix for annoyance where header menus would get scroller arrows added because it would be clamped within the screen a few pixels. This was caused from using theme shadow setting to clip the popups and a hard-coded value to translate the popup within screen bounds - these values should be the same.
2013-02-07 02:03:31 +00:00
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
rcti rect, rect_bounds;
int ofs_dummy[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
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
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
xmax = WM_window_pixels_x(window);
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
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
oldwidth = BLI_rctf_size_x(&block->rect);
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 */
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
width = BLI_rctf_size_x(&block->rect);
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
oldwidth = oldwidth > 0 ? oldwidth : MAX2(1, width);
oldheight = oldheight > 0 ? oldheight : MAX2(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: 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
raw_x = rect.xmin = xy[0] + block->rect.xmin + (block->bounds_offset[0] * width) / oldwidth;
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;
rect_bounds.xmin = margin;
rect_bounds.ymin = margin;
rect_bounds.xmax = xmax - margin;
rect_bounds.ymax = ymax - UI_POPUP_MENU_TOP;
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,
* see T52999. */
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
}
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
/* used for various cases */
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (block == NULL)
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: 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
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
/* used for pulldowns */
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
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
/* used for block popups */
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: 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
if (bounds_offset != NULL) {
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
}
/* used for menu popups */
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: 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
if (bounds_offset != NULL) {
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;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
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
/* used for centered popups, i.e. splash */
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 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
{
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
int prec = (int)but->a2;
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:
* * If button is radians, we want additional precision (see T39861).
* * 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 ************* */
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
/* NOTE: if but->poin is allocated memory for every defbut, 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
{
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 */
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 (but->retval != oldbut->retval) return false;
if (but->rnapoin.data != oldbut->rnapoin.data) return false;
Fix for button comparisons ignoring rna-index
2014-02-08 01:33:39 +11:00
if (but->rnaprop != oldbut->rnaprop || but->rnaindex != oldbut->rnaindex) 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
if (but->func != oldbut->func) return false;
if (but->funcN != oldbut->funcN) return false;
if (oldbut->func_arg1 != oldbut && but->func_arg1 != oldbut->func_arg1) return false;
if (oldbut->func_arg2 != oldbut && but->func_arg2 != oldbut->func_arg2) return false;
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) ||
(but->pointype != oldbut->pointype))) 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
if (but->optype != oldbut->optype) 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
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
{
uiBut *but_old;
for (but_old = block_old->buttons.first; but_old; but_old = but_old->next) {
if (ui_but_equals_old(but_new, but_old)) {
break;
}
}
return but_old;
}
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)
{
uiBut *but_new;
for (but_new = block_new->buttons.first; but_new; but_new = but_new->next) {
if (ui_but_equals_old(but_new, but_old)) {
break;
}
}
return but_new;
}
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
{
Code cleanup: Minor addition to rB254aa8f3a0fbffcbcb886cfaa81b630ae3e9bb78: handle copying of drawflag in ui_but_update_from_old_block() Note that this is not really needed currently, as the only flag being copied here (UI_BUT_REDALERT) remained in but->flag. However, since we'll have more flags in drawflag now, it's better to explicitly handle this situation... This func could use some cleanup anyway (a bunch of commented code here)... Thanks to Campbell for noting this!
2013-11-21 20:25:31 +01:00
const int drawflag_copy = 0; /* None currently. */
fix [#37007] Save to file - increment number doesn't update background color of filename field if hovered
2013-10-09 15:36:04 +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;
uiBut *oldbut = NULL, *but = *but_p;
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
bool found_active = 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: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
#if 0
/* simple/stupid - search every time */
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
oldbut = ui_but_find_old(oldblock, but);
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
(void)but_old_p;
#else
BLI_assert(*but_old_p == NULL || BLI_findindex(&oldblock->buttons, *but_old_p) != -1);
/* fastpath - avoid loop-in-loop, calling 'ui_but_find_old'
* as long as old/new buttons are aligned */
if (LIKELY(*but_old_p && ui_but_equals_old(but, *but_old_p))) {
oldbut = *but_old_p;
}
else {
/* fallback to block search */
oldbut = ui_but_find_old(oldblock, but);
}
(*but_old_p) = oldbut ? oldbut->next : NULL;
#endif
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
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) {
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
return found_active;
UI: avoid O(n2) for old button lookups since both lists are almost always aligned
2014-02-08 02:22:32 +11:00
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
if (oldbut->active) {
Fix own error in recent commit with red-alert flag becoming stale
2014-02-13 09:12:47 +11:00
/* flags from the buttons we want to refresh, may want to add more here... */
Fix T51776: Make sure button icons are updated on Ctrl-ScrollWheel
2017-07-27 12:55:17 +02:00
const int flag_copy = UI_BUT_REDALERT | UI_HAS_ICON;
Fix own error in recent commit with red-alert flag becoming stale
2014-02-13 09:12:47 +11:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11: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
bugfix [#24575] On file save plus and minus don't re-evaluate whether a file exists actually it was re-evaluated. just the flag was overwritten by the old button.
2010-11-07 05:35:41 +00:00
#if 0
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
but->flag = oldbut->flag;
but->active = oldbut->active;
but->pos = oldbut->pos;
but->ofs = oldbut->ofs;
but->editstr = oldbut->editstr;
but->editval = oldbut->editval;
but->editvec = oldbut->editvec;
but->editcoba = oldbut->editcoba;
but->editcumap = oldbut->editcumap;
but->selsta = oldbut->selsta;
but->selend = oldbut->selend;
but->softmin = oldbut->softmin;
but->softmax = oldbut->softmax;
oldbut->active = NULL;
bugfix [#24575] On file save plus and minus don't re-evaluate whether a file exists actually it was re-evaluated. just the flag was overwritten by the old button.
2010-11-07 05:35:41 +00:00
#endif
Code cleanup: Minor addition to rB254aa8f3a0fbffcbcb886cfaa81b630ae3e9bb78: handle copying of drawflag in ui_but_update_from_old_block() Note that this is not really needed currently, as the only flag being copied here (UI_BUT_REDALERT) remained in but->flag. However, since we'll have more flags in drawflag now, it's better to explicitly handle this situation... This func could use some cleanup anyway (a bunch of commented code here)... Thanks to Campbell for noting this!
2013-11-21 20:25:31 +01:00
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
/* move button over from oldblock to new block */
BLI_remlink(&oldblock->buttons, oldbut);
BLI_insertlinkafter(&block->buttons, but, oldbut);
oldbut->block = block;
*but_p = oldbut;
/* 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) {
SWAP(char *, oldbut->poin, but->poin);
SWAP(void *, oldbut->func_argN, but->func_argN);
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
SWAP(void *, oldbut->tip_argN, but->tip_argN);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
oldbut->flag = (oldbut->flag & ~flag_copy) | (but->flag & flag_copy);
oldbut->drawflag = (oldbut->drawflag & ~drawflag_copy) | (but->drawflag & drawflag_copy);
/* copy hardmin for list rows to prevent 'sticking' highlight to mouse position
* when scrolling without moving mouse (see [#28432]) */
Fix T47256: Progress bar doesn't update w/ mouse-over
2016-02-02 14:06:06 +11:00
if (ELEM(oldbut->type, UI_BTYPE_ROW, UI_BTYPE_LISTROW)) {
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
oldbut->hardmax = but->hardmax;
Fix T47256: Progress bar doesn't update w/ mouse-over
2016-02-02 14:06:06 +11:00
}
/* Selectively copy a1, a2 since their use differs across all button types
* (and we'll probably split these out later) */
if (ELEM(oldbut->type, UI_BTYPE_PROGRESS_BAR)) {
oldbut->a1 = but->a1;
}
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11: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);
}
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
/* move/copy string from the new button to the old */
/* needed for alt+mouse wheel over enums */
if (but->str != but->strdata) {
if (oldbut->str != oldbut->strdata) {
SWAP(char *, but->str, oldbut->str);
}
else {
oldbut->str = but->str;
but->str = but->strdata;
}
}
else {
if (oldbut->str != oldbut->strdata) {
MEM_freeN(oldbut->str);
oldbut->str = oldbut->strdata;
}
BLI_strncpy(oldbut->strdata, but->strdata, sizeof(oldbut->strdata));
}
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if (but->dragpoin && (but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
SWAP(void *, but->dragpoin, oldbut->dragpoin);
}
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);
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
/* note: if layout hasn't been applied yet, it uses old button pointers... */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 {
Fix own error in recent commit with red-alert flag becoming stale
2014-02-13 09:12:47 +11:00
const int flag_copy = UI_BUT_DRAG_MULTI;
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);
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
}
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
}
style cleanup - spelling.
2012-03-08 04:12:11 +00:00
/* needed for temporarily rename buttons, such as in outliner or file-select,
correct indentation and some whitespace edits (no functional changes)
2011-11-11 13:09:14 +00:00
* they should keep calling uiDefButs to keep them alive */
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
/* returns 0 when button removed */
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_active_only(const bContext *C, ARegion *ar, uiBlock *block, uiBut *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
{
uiBlock *oldblock;
uiBut *oldbut;
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;
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
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 {
Code cleanup: move old->new button search into ui_but_find_old
2014-02-08 01:46:43 +11:00
oldbut = ui_but_find_old(oldblock, but);
if (oldbut) {
found = true;
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)) {
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_activate_event((bContext *)C, ar, 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)) {
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
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);
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
}
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 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
}
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 UI_block_active_only_flagged_buttons(const bContext *C, ARegion *ar, uiBlock *block)
{
bool done = false;
for (uiBut *but = block->buttons.first; but; but = but->next) {
if (!done && ui_but_is_editable(but)) {
if (but->flag & UI_BUT_ACTIVATE_ON_INIT) {
if (UI_but_active_only(C, ar, block, but)) {
done = true;
}
}
}
but->flag &= ~UI_BUT_ACTIVATE_ON_INIT;
}
return done;
}
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
/* simulate button click */
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_execute(const bContext *C, 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
ARegion *ar = CTX_wm_region(C);
void *active_back;
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_execute_begin((bContext *)C, ar, 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. */
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_execute_end((bContext *)C, ar, 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
{
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->rnapoin.id.data) {
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
/* avoid undo push for buttons who's ID are screen or wm level
* we could disable undo for buttons with no ID too but may have
spelling corrections in comments and quiet warning
2011-10-15 14:14:22 +00:00
* unforeseen consequences, so best check for ID's we _know_ are not
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
* handled by undo - campbell */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ID *id = but->rnapoin.id.data;
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
if (ID_CHECK_UNDO(id) == false) {
return false;
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
}
else {
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
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
}
}
- 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
else if (but->rnapoin.type && !RNA_struct_undo_check(but->rnapoin.type)) {
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
}
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
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
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
}
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)
{
uiBut *but;
Cleanup: use typed unsigned ints
2019-01-04 11:05:53 +11:00
uint menu_key_mask = 0;
uchar menu_key;
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
const char *str_pt;
int pass;
style cleanup: interface
2012-03-30 01:51:25 +00:00
int tot_missing = 0;
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 */
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
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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (pass = 0; pass < 2; pass++) {
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
/* 2 Passes, on for first letter only, second for any letter if first fails
* fun first pass on all buttons so first word chars always get first priority */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (but = block->buttons.first; but; but = but->next) {
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_BTYPE_PULLDOWN) ||
(but->flag & UI_HIDDEN))
{
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
/* pass */
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (but->menu_key == '\0') {
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->str) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (str_pt = but->str; *str_pt; ) {
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');
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;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (pass == 0) {
style cleanup - spelling.
2012-03-08 04:12:11 +00:00
/* Skip to next delimiter on first pass (be picky) */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
while (isalpha(*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
str_pt++;
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 (*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
str_pt++;
}
else {
/* just step over every char second pass and find first usable key */
str_pt++;
}
}
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 (*str_pt) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->menu_key = menu_key;
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
}
else {
/* run second pass */
tot_missing++;
}
/* if all keys have been used just exit, unlikely */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (menu_key_mask == (1 << 26) - 1) {
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;
}
}
}
}
/* 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;
}
}
}
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
/* XXX, this code will shorten any allocated string to 'UI_MAX_NAME_STR'
* since this is really long its unlikely to be an issue,
* but this could be supported */
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)) {
char *cpoin = strrchr(but->str, UI_SEP_CHAR);
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 (cpoin) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
*cpoin = '\0';
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
}
/* without this, just allow stripping of the shortcut */
if (shortcut_str) {
char *butstr_orig;
if (but->str != but->strdata) {
butstr_orig = but->str; /* free after using as source buffer */
}
else {
butstr_orig = BLI_strdup(but->str);
}
Cleanup: right shift in interface code
2018-07-01 19:57:31 +02:00
BLI_snprintf(
but->strdata,
sizeof(but->strdata),
"%s" UI_SEP_CHAR_S "%s",
butstr_orig, shortcut_str);
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
MEM_freeN(butstr_orig);
but->str = but->strdata;
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
but->flag |= UI_BUT_HAS_SEP_CHAR;
Fix dimmed shortcut key display issues in toolbar menu and color picker. Draw with alpha * 0.5 instead of using item them color, this doesn't work well in the toolbar menu and highlighted menu items otherwise.
2018-07-03 13:04:21 +02:00
but->drawflag |= UI_BUT_HAS_SHORTCUT;
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);
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
* \{ */
static bool ui_but_event_operator_string_from_operator(
Cleanup: order buffer length after the buffer
2017-11-06 00:04:46 +11:00
const bContext *C, uiBut *but,
char *buf, const size_t buf_len)
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: split keymap lookups into own functions More will be added in 2.8, keep this manageable.
2018-07-13 10:26:24 +02:00
BLI_assert(but->optype != NULL);
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
bool found = false;
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
IDProperty *prop = (but->opptr) ? but->opptr->data : NULL;
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +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
if (WM_key_event_operator_string(
C, but->optype->idname, but->opcontext, prop, true,
buf, buf_len))
{
found = true;
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +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
return found;
}
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +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
static bool ui_but_event_operator_string_from_menu(
const bContext *C, uiBut *but,
char *buf, const size_t buf_len)
{
MenuType *mt = UI_but_menutype_get(but);
BLI_assert(mt != NULL);
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +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
bool found = false;
Cleanup: id-property API use Also clarify comments.
2018-07-13 10:51:49 +02:00
IDProperty *prop_menu;
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +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
/* annoying, create a property */
IDPropertyTemplate val = {0};
prop_menu = IDP_New(IDP_GROUP, &val, __func__); /* dummy, name is unimportant */
Cleanup: id-property API use Also clarify comments.
2018-07-13 10:51:49 +02:00
IDP_AddToGroup(prop_menu, IDP_NewString(mt->idname, "name", sizeof(mt->idname)));
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
if (WM_key_event_operator_string(
Cleanup: unused args, indentation
2018-11-21 06:21:58 +11:00
C, "WM_OT_call_menu", WM_OP_INVOKE_REGION_WIN, prop_menu, true,
buf, buf_len))
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
{
found = true;
}
IDP_FreeProperty(prop_menu);
MEM_freeN(prop_menu);
return found;
}
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
static bool ui_but_event_operator_string_from_panel(
const bContext *C, uiBut *but,
char *buf, const size_t buf_len)
{
/** Nearly exact copy of #ui_but_event_operator_string_from_menu */
PanelType *pt = UI_but_paneltype_get(but);
BLI_assert(pt != NULL);
bool found = false;
IDProperty *prop_panel;
/* annoying, create a property */
IDPropertyTemplate val = {0};
prop_panel = IDP_New(IDP_GROUP, &val, __func__); /* dummy, name is unimportant */
IDP_AddToGroup(prop_panel, IDP_NewString(pt->idname, "name", sizeof(pt->idname)));
IDP_AddToGroup(prop_panel, IDP_New(IDP_INT, &(IDPropertyTemplate){ .i = pt->space_type, }, "space_type"));
IDP_AddToGroup(prop_panel, IDP_New(IDP_INT, &(IDPropertyTemplate){ .i = pt->region_type, }, "region_type"));
for (int i = 0; i < 2; i++) {
/* FIXME(campbell): We can't reasonably search all configurations - long term. */
IDP_ReplaceInGroup(prop_panel, IDP_New(IDP_INT, &(IDPropertyTemplate){ .i = i, }, "keep_open"));
if (WM_key_event_operator_string(
C, "WM_OT_call_panel", WM_OP_INVOKE_REGION_WIN, prop_panel, true,
buf, buf_len))
{
found = true;
break;
}
}
IDP_FreeProperty(prop_panel);
MEM_freeN(prop_panel);
return found;
}
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
static bool ui_but_event_operator_string(
const bContext *C, uiBut *but,
char *buf, const size_t buf_len)
{
bool found = false;
if (but->optype != NULL) {
found = ui_but_event_operator_string_from_operator(C, but, buf, buf_len);
}
else if (UI_but_menutype_get(but) != NULL) {
found = ui_but_event_operator_string_from_menu(C, but, buf, buf_len);
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
}
UI: show popover shortcuts in tooltip
2018-07-13 10:57:25 +02:00
else if (UI_but_paneltype_get(but) != NULL) {
found = ui_but_event_operator_string_from_panel(C, but, buf, buf_len);
}
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
display menu items key shortcuts in the button tooltips.
2013-06-01 05:53:44 +00:00
return found;
}
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
Cleanup: order buffer length after the buffer
2017-11-06 00:04:46 +11:00
static bool ui_but_event_property_operator_string(
const bContext *C, uiBut *but,
char *buf, const size_t buf_len)
{
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
/* context toggle operator names to check... */
Fix crash creating enum tooltips Error from recent changes to shortcut display.
2018-11-30 08:01:41 +11:00
/* This function could use a refactor to generalize button type to operator relationship
* as well as which operators use properties.
* - Campbell
* */
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: trailing commas Needed for clan-format not to wrap onto one line.
2019-02-03 14:01:45 +11:00
NULL,
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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: trailing commas Needed for clan-format not to wrap onto one line.
2019-02-03 14:01:45 +11:00
NULL,
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11: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: trailing commas Needed for clan-format not to wrap onto one line.
2019-02-03 14:01:45 +11:00
NULL,
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);
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;
if ((but->type == UI_BTYPE_BUT_MENU) && (but->block->handle != NULL)) {
uiBut *but_parent = but->block->handle->popup_create_vars.but;
if ((but->type == UI_BTYPE_BUT_MENU) &&
Fix crash creating enum tooltips Error from recent changes to shortcut display.
2018-11-30 08:01:41 +11:00
(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) &&
Fix crash creating enum tooltips Error from recent changes to shortcut display.
2018-11-30 08:01:41 +11:00
(but_parent->menu_create_func == ui_def_but_rna__menu))
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11: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;
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
}
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
bool found = false;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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. */
but = NULL;
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* this version is only for finding hotkeys for properties
* (which get set via context using operators) */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (prop) {
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* to avoid massive slowdowns on property panels, for now, we only check the
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
* hotkeys for Editor / Scene settings...
*
* TODO: userpref settings?
*/
char *data_path = NULL;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (ptr->id.data) {
ID *id = ptr->id.data;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
if (GS(id->name) == ID_SCR) {
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* screen/editor property
* NOTE: in most cases, there is actually no info for backwards tracing
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
* how to get back to ID from the editor data we may be dealing with
*/
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (RNA_struct_is_a(ptr->type, &RNA_Space)) {
/* data should be directly on here... */
data_path = BLI_sprintfN("space_data.%s", RNA_property_identifier(prop));
}
else if (RNA_struct_is_a(ptr->type, &RNA_Area)) {
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
/* data should be directly on here... */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
const char *prop_id = RNA_property_identifier(prop);
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
/* Hack since keys access 'type', UI shows 'ui_type'. */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (STREQ(prop_id, "ui_type")) {
prop_id = "type";
prop_enum_value >>= 16;
prop = RNA_struct_find_property(ptr, prop_id);
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11: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;
}
else {
data_path = BLI_sprintfN("area.%s", prop_id);
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +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
}
else {
/* special exceptions for common nested data in editors... */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (RNA_struct_is_a(ptr->type, &RNA_DopeSheet)) {
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
/* dopesheet filtering options... */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
data_path = BLI_sprintfN("space_data.dopesheet.%s", RNA_property_identifier(prop));
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
}
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
else if (RNA_struct_is_a(ptr->type, &RNA_FileSelectParams)) {
Fix FileBrowser 'context-editing' properties shortcuts not being displayed in tooltip. Also related to T46918.
2015-12-03 12:50:09 +01:00
/* Filebrowser options... */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
data_path = BLI_sprintfN("space_data.params.%s", RNA_property_identifier(prop));
Fix FileBrowser 'context-editing' properties shortcuts not being displayed in tooltip. Also related to T46918.
2015-12-03 12:50:09 +01: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
}
}
else if (GS(id->name) == ID_SCE) {
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
if (RNA_struct_is_a(ptr->type, &RNA_ToolSettings)) {
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* toolsettings property
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
* NOTE: toolsettings is usually accessed directly (i.e. not through scene)
*/
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
data_path = RNA_path_from_ID_to_property(ptr, prop);
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
}
else {
/* scene property */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
char *path = RNA_path_from_ID_to_property(ptr, prop);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
if (path) {
data_path = BLI_sprintfN("scene.%s", path);
MEM_freeN(path);
}
minor style clanup and use more meaningful name for 3DCONNEXION source code.
2013-09-14 12:04:10 +00:00
#if 0
else {
printf("ERROR in %s(): Couldn't get path for scene property - %s\n",
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
__func__, RNA_property_identifier(prop));
minor style clanup and use more meaningful name for 3DCONNEXION source code.
2013-09-14 12:04:10 +00:00
}
#endif
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
}
}
else {
//puts("other id");
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
//printf("prop shortcut: '%s' (%s)\n", RNA_property_identifier(prop), data_path);
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: strip trailing space from interface files
2018-05-23 10:47:12 +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
/* we have a datapath! */
Keymap: fix error in recent enum-menu support
2018-12-02 15:09:15 +11:00
if (data_path || (prop_enum_value_ok && prop_enum_value_id)) {
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
/* create a property to host the "datapath" property we're sending to the operators */
IDProperty *prop_path;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
IDPropertyTemplate val = {0};
prop_path = IDP_New(IDP_GROUP, &val, __func__);
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
if (data_path) {
IDP_AddToGroup(prop_path, IDP_NewString(data_path, "data_path", strlen(data_path) + 1));
}
if (prop_enum_value_ok) {
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
const EnumPropertyItem *item;
bool free;
RNA_property_enum_items((bContext *)C, ptr, prop, &item, NULL, &free);
int index = RNA_enum_from_value(item, prop_enum_value);
if (index != -1) {
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
IDProperty *prop_value;
if (prop_enum_value_is_int) {
int value = item[index].value;
prop_value = IDP_New(IDP_INT, &(IDPropertyTemplate){ .i = value, }, prop_enum_value_id);
}
else {
const char *id = item[index].identifier;
prop_value = IDP_NewString(id, prop_enum_value_id, strlen(id) + 1);
}
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 {
opnames_len = 0; /* Do nothing. */
}
if (free) {
MEM_freeN((void *)item);
}
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
/* check each until one works... */
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
for (int i = 0; (i < opnames_len) && (opnames[i]); i++) {
Cleanup: order buffer length after the buffer
2017-11-06 00:04:46 +11:00
if (WM_key_event_operator_string(
UI: support enum key shortcut detection Shows shortcuts in space-selector.
2018-11-29 17:32:35 +11:00
C, opnames[i], WM_OP_INVOKE_REGION_WIN, prop_path, false,
Cleanup: unused args, indentation
2018-11-21 06:21:58 +11:00
buf, buf_len))
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
{
found = true;
break;
}
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
/* cleanup */
IDP_FreeProperty(prop_path);
MEM_freeN(prop_path);
UI: update shortcut display to check space cycling
2018-11-29 18:45:37 +11:00
if (data_path) {
MEM_freeN(data_path);
}
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: strip trailing space from interface files
2018-05-23 10:47:12 +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
return found;
}
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: 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
* as new items are added to the menu later on. It also optimises efficiency -
* 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
*/
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};
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
static void ui_but_pie_direction_string(uiBut *but, char *buf, int size)
{
BLI_assert(but->pie_dir < ARRAY_SIZE(ui_radial_dir_to_numpad));
BLI_snprintf(buf, size, "%d", ui_radial_dir_to_numpad[but->pie_dir]);
}
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)
{
uiBut *but;
char buf[128];
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));
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
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;
}
if (STREQ(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
}
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
if (block->flag & UI_BLOCK_RADIAL) {
for (but = block->buttons.first; but; but = but->next) {
if (but->pie_dir != UI_RADIAL_NONE) {
ui_but_pie_direction_string(but, buf, sizeof(buf));
ui_but_add_shortcut(but, buf, false);
}
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 {
for (but = block->buttons.first; but; but = but->next) {
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;
}
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
else 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
}
else if (but->dt != 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;
}
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 (ui_but_event_operator_string(C, but, buf, sizeof(buf))) {
ui_but_add_shortcut(but, buf, false);
}
else if (ui_but_event_property_operator_string(C, but, buf, sizeof(buf))) {
ui_but_add_shortcut(but, buf, false);
}
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
}
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
void ui_but_override_flag(uiBut *but)
{
Rename: RNA_property_override_status > RNA_property_static_override_status
2018-05-09 16:17:15 +02:00
const int override_status = RNA_property_static_override_status(&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) {
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
but->flag |= UI_BUT_OVERRIDEN;
}
else {
but->flag &= ~UI_BUT_OVERRIDEN;
}
}
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
{
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
uiBut *but_old;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
uiBut *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
if (!block->oldblock)
return;
but_old = 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: 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
for (but = block->buttons.first; but; but = but->next) {
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
block->oldblock = NULL;
}
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);
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
uiBut *but;
BLI_assert(block->active);
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);
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
/* 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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (but = block->buttons.first; but; but = but->next) {
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;
UI: * Make modifier and constraint templates use left/right alignment for buttons in the header. * Added mdef bind operator as an example of how to use local context for a modifier, and add some code I forgot to commit last time to make this system actually work.
2009-06-03 00:09:30 +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->context)
style cleanup: interface
2012-03-30 01:51:25 +00:00
CTX_store_set((bContext *)C, but->context);
UI: * Make modifier and constraint templates use left/right alignment for buttons in the header. * Added mdef bind operator as an example of how to use local context for a modifier, and add some code I forgot to commit last time to make this system actually work.
2009-06-03 00:09:30 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (ot == NULL || WM_operator_poll_context((bContext *)C, ot, but->opcontext) == 0) {
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;
}
UI: * Make modifier and constraint templates use left/right alignment for buttons in the header. * Added mdef bind operator as an example of how to use local context for a modifier, and add some code I forgot to commit last time to make this system actually work.
2009-06-03 00:09:30 +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->context)
style cleanup: interface
2012-03-30 01:51:25 +00:00
CTX_store_set((bContext *)C, NULL);
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: * 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
ui_but_anim_flag(but, (scene) ? scene->r.cfra : 0.0f);
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
ui_but_override_flag(but);
UI: show decorator icon for static-override
2018-06-16 18:26:34 +02:00
if (UI_but_is_decorator(but)) {
ui_but_anim_decorate_update_from_flag(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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: 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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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) {
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_resolve(block, NULL, NULL);
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));
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) && (block->flag & UI_BLOCK_NUMSELECT)) {
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 */
}
code cleanup: use typedef'd enum for block bounds types.
2012-09-10 07:03:30 +00: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);
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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;
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
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;
}
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
}
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: 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);
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->endblock = 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
}
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);
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_end_ex(C, block, &window->eventstate->x, NULL);
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 ************* */
2.5 Fixed & upgraded tooltips to new drawing system. Also fixed small error in menu shadows. Rounding of shadow below menu went wrong.
2009-04-15 14:43:54 +00:00
void ui_fontscale(short *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
{
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 (aspect < 0.9f || aspect > 1.1f) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
float pointsf = *points;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
/* for some reason scaling fonts goes too fast compared to widget size */
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
/* XXX not true anymore? (ton) */
//aspect = sqrt(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
pointsf /= aspect;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 (aspect > 1.0f)
style cleanup: interface
2012-03-30 01:51:25 +00:00
*points = ceilf(pointsf);
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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
*points = floorf(pointsf);
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
}
}
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
/* project button or block (but==NULL) to pixels in regionspace */
static void ui_but_to_pixelrect(rcti *rect, const ARegion *ar, uiBlock *block, uiBut *but)
{
fix [#35346] Python: still UI issue with popup and dropdown list
2013-06-13 09:12:53 +00:00
rctf rectf;
ui_block_to_window_rctf(ar, block, &rectf, (but) ? &but->rect : &block->rect);
Fix T51845
2017-06-23 11:04:58 +03:00
BLI_rcti_rctf_copy_round(rect, &rectf);
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_translate(rect, -ar->winrct.xmin, -ar->winrct.ymin);
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
}
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
/* uses local copy of style, to scale things down, and allow widgets to change stuff */
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 */
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
ARegion *ar;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
uiBut *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
rcti rect;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = CTX_wm_menu(C);
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 (!ar)
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = CTX_wm_region(C);
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00: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);
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
GLRefactor: partially remove gl calls from source/blender/editors. This translates the gl calls to the new GPU_ wrappers from D3501. Given it's tedious and repetitive work, this patch does as much as it can with search + replace, the remainder of the gl calls will need to be manually dealt with on a case by case basis. This fixes 13 of the 28 failing editors when building without opengl. For the list of substitutions see D3502 Reviewers: brecht Differential Revision: https://developer.blender.org/D3502
2018-06-27 19:07:23 -06:00
GPU_blend_set_func_separate(GPU_SRC_ALPHA, GPU_ONE_MINUS_SRC_ALPHA, GPU_ONE, GPU_ONE_MINUS_SRC_ALPHA);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 */
ui_but_to_pixelrect(&rect, ar, block, NULL);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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();
WM: Add utility wmOrtho2_*** funcs Currently there are inconsistencies with pixel alignment. but this commit has no functional changes. - wmOrtho2_region_ui for UI/Text. - wmOrtho2_region_pixelspace for 2D drawing. - wmOrtho2_pixelspace - when the region isn't used.
2014-09-10 13:24:31 +10:00
Cleanup: Duplicated function wmOrtho2_region_pixelspace and wmOrtho2_region_ui were doing exact same thing since rBSa86482f81cf3.
2016-02-29 15:20:09 +01:00
wmOrtho2_region_pixelspace(ar);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 */
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_draw_pie_center(block);
UI: support for center popovers over buttons
2018-04-22 22:08:48 +02:00
else if (block->flag & UI_BLOCK_POPOVER)
UI: show popover arrow directly under the button A visual hint but looks broken when its not pointing to the button.
2018-04-28 22:54:11 +02:00
ui_draw_popover_back(ar, &style, block, &rect);
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
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);
UI: use popup draw style for redo panel
2018-09-11 11:22:08 +10:00
else if (block->panel) {
bool show_background = ar->alignment != RGN_ALIGN_FLOAT;
ui_draw_aligned_panel(
&style, block, &rect,
UI_panel_category_is_visible(ar), show_background);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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();
UI: Perf: Add BLF batching for File browser and UI blocks. This batch together most of the calls that can be batch together.
2018-03-30 21:09: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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (but = block->buttons.first; but; but = but->next) {
if (!(but->flag & (UI_HIDDEN | UI_SCROLLED))) {
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
ui_but_to_pixelrect(&rect, ar, block, but);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Temporary fix for [#23848] Image too small Error * This should be fixed properly later when general window close/resize problems in the todo list are tackled.
2010-09-21 14:39:18 +00:00
/* XXX: figure out why invalid coordinates happen when closing render window */
/* and material preview is redrawn in main window (temp fix for bug #23848) */
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 (rect.xmin < rect.xmax && rect.ymin < rect.ymax)
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
ui_draw_but(C, ar, &style, but, &rect);
}
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: Perf: Add BLF batching for File browser and UI blocks. This batch together most of the calls that can be batch together.
2018-03-30 21:09: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();
Fix: selecting with z-buffer hiding did not work when graphics card settings enabled antialiasing, overriding application settings. The fix for this got lost when the FSAA option was added and later disabled again. Added it back now, and also disable AA for UI widgets since it makes them look too blurry, they already do their own AA.
2011-10-31 14:08:14 +00:00
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
}
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
static void ui_block_message_subscribe(ARegion *ar, struct wmMsgBus *mbus, uiBlock *block)
{
uiBut *but_prev = NULL;
/* possibly we should keep the region this block is contained in? */
for (uiBut *but = block->buttons.first; but; but = but->next) {
if (but->rnapoin.type && but->rnaprop) {
/* quick check to avoid adding buttons representing a vector, multiple times. */
if ((but_prev &&
Cleanup: unused args, indentation
2018-11-21 06:21:58 +11:00
(but_prev->rnaprop == but->rnaprop) &&
(but_prev->rnapoin.type == but->rnapoin.type) &&
(but_prev->rnapoin.data == but->rnapoin.data) &&
(but_prev->rnapoin.id.data == but->rnapoin.id.data)) == 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. */
WM_msg_subscribe_rna(
mbus, &but->rnapoin, but->rnaprop,
&(const wmMsgSubscribeValue){
.owner = ar,
.user_data = ar,
.notify = ED_region_do_msg_notify_tag_redraw,
}, __func__);
but_prev = but;
}
}
}
}
void UI_region_message_subscribe(ARegion *ar, struct wmMsgBus *mbus)
{
for (uiBlock *block = ar->uiblocks.first; block; block = block->next) {
ui_block_message_subscribe(ar, mbus, 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
/* ************* EVENTS ************* */
Code Cleanup: remove redundant NULL checks and add function attributes
2014-01-20 11:13:53 +11:00
/**
* Check if the button is pushed, this is only meaningful for some button types.
*
Code Cleanup: use bool for return values and correct comments also remove CDDM_Check, theres no need for it.
2014-01-22 02:48:11 +11:00
* \return (0 == UNSELECT), (1 == SELECT), (-1 == DO-NOTHING)
Code Cleanup: remove redundant NULL checks and add function attributes
2014-01-20 11:13:53 +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_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;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if (but->bit) {
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 bool state = ELEM(but->type, UI_BTYPE_TOGGLE_N, UI_BTYPE_ICON_TOGGLE_N, UI_BTYPE_CHECKBOX_N) ? false : true;
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);
style cleanup: interface
2012-03-30 01:51:25 +00: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;
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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:
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);
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00:00
if (*value != (double)but->hardmin) 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);
code cleanup: minor refactor of button pressed state checking, needed for drag toggle fix.
2013-03-01 00:19:32 +00: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) {
PointerRNA active_ptr = RNA_property_pointer_get(&but->rnapoin, but->rnaprop);
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;
}
UI_GET_BUT_VALUE_INIT(but, *value);
/* support for rna enum buts */
if (but->rnaprop && (RNA_property_flag(but->rnaprop) & PROP_ENUM_FLAG)) {
if ((int)*value & (int)but->hardmax) is_push = true;
}
else {
if (*value == (double)but->hardmax) 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;
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
}
}
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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->lockstr = NULL;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
/* Get PointerRNA which will point to a data inside of an evaluated
* ID datablock.
*/
static PointerRNA ui_but_evaluated_rnapoin_get(uiBut *but)
{
BLI_assert(but->rnaprop != NULL);
/* TODO(sergey): evil_C sounds.. EVIL! Any clear way to avoid this? */
PointerRNA rnapoin_eval = but->rnapoin;
/* If there is no animation or drivers, it doesn't matter if we read value
* from evaluated datablock or from original one.
*
* Reading from original one is much faster, since we don't need to do any
* PointerRNA remapping or hash lookup.
*/
if (BKE_animdata_from_id(but->rnapoin.id.data) == NULL) {
return rnapoin_eval;
}
/* Same goes for the properties which can not be animated. */
if (!RNA_property_animateable(&but->rnapoin, but->rnaprop)) {
return rnapoin_eval;
}
Depsgraph *depsgraph = CTX_data_depsgraph(but->block->evil_C);
/* ID pointer we can always remap, they are inside of depsgraph. */
rnapoin_eval.id.data =
DEG_get_evaluated_id(depsgraph, rnapoin_eval.id.data);
/* Some of ID datablocks do not have their evaluated copy inside
* of dependency graph. If it's such datablock, no need to worry about
* data pointer.
*/
if (rnapoin_eval.id.data == but->rnapoin.id.data) {
return rnapoin_eval;
}
/* For the data pointer it's getting a bit more involved, since it can
* whether be and ID, or can be a property deep inside of ID.
*
* We start from checking if it's an ID, since that is the less involved
* code path, and probably is executed in most of the cases.
*/
if (but->rnapoin.data == but->rnapoin.id.data) {
rnapoin_eval.data = DEG_get_evaluated_id(depsgraph, rnapoin_eval.data);
return rnapoin_eval;
}
/* We aren't as lucky as we thought we are :(
*
* Since we don't know what the property is, we get it's RNA path
* relative to the original ID, and then we decent down from evaluated
* ID to the same property.
*
* This seems to be most straightforward way to get sub-data pointers
* which can be buried deep inside of ID block.
*/
const char *rna_path =
RNA_path_from_ID_to_property(&but->rnapoin, but->rnaprop);
if (rna_path != NULL) {
PointerRNA id_ptr;
RNA_id_pointer_create(rnapoin_eval.id.data, &id_ptr);
if (!RNA_path_resolve_full(&id_ptr,
rna_path,
&rnapoin_eval,
NULL, NULL))
{
/* TODO(sergey): Anything to do here to recover? */
}
MEM_freeN((void *)rna_path);
}
return rnapoin_eval;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* for buttons pointing to color 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
{
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
PropertyRNA *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
int a;
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
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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->rnaprop) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
prop = but->rnaprop;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00: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);
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
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
PointerRNA rnapoin_eval = ui_but_evaluated_rnapoin_get(but);
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) {
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
int tot = RNA_property_array_length(&rnapoin_eval, 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) {
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
RNA_property_float_get_array(&rnapoin_eval, 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);
for (a = 0; a < tot; a++) {
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
vec[a] = RNA_property_float_get_index(&rnapoin_eval, 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;
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
style cleanup: interface
2012-03-30 01:51:25 +00: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 {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->editvec == NULL) {
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
}
}
fix UI jump in normal buttons for buttons which didnt start out normalized.
2011-10-15 09:43: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
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
}
/* for buttons pointing to color 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_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
{
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
PropertyRNA *prop;
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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->rnaprop) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
prop = but->rnaprop;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (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;
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;
cp[0] = (char)(0.5f + vec[0] * 255.0f);
cp[1] = (char)(0.5f + vec[1] * 255.0f);
cp[2] = (char)(0.5f + 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
{
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_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: strip trailing space from interface files
2018-05-23 10:47:12 +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 && 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: 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 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
{
UI: activate tabs immediately on press, and drag to quickly cycle through.
2018-11-22 21:10:12 +01:00
if (ELEM(but->type, UI_BTYPE_TOGGLE, UI_BTYPE_TOGGLE_N, UI_BTYPE_ICON_TOGGLE, UI_BTYPE_ICON_TOGGLE_N, 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;
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
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;
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: add Shift-Drag to multiselect expanded enum items too. Differential Revision: https://developer.blender.org/D928
2014-12-10 17:00:54 +01:00
if ((but->rnaprop && RNA_property_type(but->rnaprop) == PROP_ENUM) && (but->type == UI_BTYPE_ROW))
return true;
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
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 (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;
- 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 */
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_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;
- 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 */
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
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;
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 for error in recent commit, wasn't masking out the non unit subtype flags.
2010-12-10 13:15:11 +00:00
if (unit_type != PROP_UNIT_ROTATION) {
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: 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
/**
* Check if this button is similar enough to be grouped with another.
*/
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
{
if (but_a->type != but_b->type)
return false;
if (but_a->pointype != but_b->pointype)
return false;
if (but_a->rnaprop) {
UI: let multi-num-drag change different ID values Handy for property-chart addon.
2014-10-29 22:35:09 +01:00
/* skip 'rnapoin.data', 'rnapoin.id.data'
* allow different data to have the same props edited at once */
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->rnapoin.type != but_b->rnapoin.type)
return false;
if (RNA_property_type(but_a->rnaprop) != RNA_property_type(but_b->rnaprop))
return false;
if (RNA_property_subtype(but_a->rnaprop) != RNA_property_subtype(but_b->rnaprop))
return false;
}
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->rnaprop == NULL || 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
}
else {
printf("property removed %s: %p\n", but->drawstr, 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 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
/**
* Checks if the button supports ctrl+mousewheel cycling
*/
bool ui_but_supports_cycling(const uiBut *but)
{
return ((ELEM(but->type, UI_BTYPE_ROW, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER, UI_BTYPE_LISTBOX)) ||
(but->type == UI_BTYPE_MENU && ui_but_menu_step_poll(but)) ||
UI: support cycling callback for non RNA menus
2015-11-16 06:26:25 +11:00
(but->type == UI_BTYPE_COLOR && but->a1 != -1) ||
(but->menu_step_func != NULL));
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
{
PropertyRNA *prop;
double value = 0.0;
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->editval) { return *(but->editval); }
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->poin == NULL && but->rnapoin.data == NULL) return 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
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
prop = but->rnaprop;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
BLI_assert(but->rnaindex != -1);
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
PointerRNA rnapoin_eval = ui_but_evaluated_rnapoin_get(but);
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:
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_array_check(prop))
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_boolean_get_index(&rnapoin_eval, prop, but->rnaindex);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_boolean_get(&rnapoin_eval, 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;
case PROP_INT:
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_array_check(prop))
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_int_get_index(&rnapoin_eval, prop, but->rnaindex);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_int_get(&rnapoin_eval, 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;
case PROP_FLOAT:
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_array_check(prop))
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_float_get_index(&rnapoin_eval, prop, but->rnaindex);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_float_get(&rnapoin_eval, 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;
case PROP_ENUM:
Interface: Show properties values from evaluated datablocks This is a way to deal with animated properties in evaluated version off datablock. Previously, running blender with copy-on-write enabled will show original values. Now we can see proper properties, while typing values in still goes to the original datablock. Thanks Brecht for the review!
2018-04-17 17:20:34 +02:00
value = RNA_property_enum_get(&rnapoin_eval, 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
}
whitespace only, no functional change mixed tabs/spaces --> tabs.
2011-04-21 13:11: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
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
{
PropertyRNA *prop;
/* 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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
prop = but->rnaprop;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (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:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00: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);
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
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);
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:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(prop))
pedantic word ordering change. - wm.add_modal_handler -> modal_handler_add - wm.add_fileselect -> fileselect_add - ob.add_shape_key -> shape_key_add - VIEW3D_OT_add_background_image -> VIEW3D_OT_background_image_add (same for remove) Also made 2 internal cmake vars hidden.
2010-12-08 11:42:11 +00:00
RNA_property_int_set_index(&but->rnapoin, prop, but->rnaindex, (int)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
else
pedantic word ordering change. - wm.add_modal_handler -> modal_handler_add - wm.add_fileselect -> fileselect_add - ob.add_shape_key -> shape_key_add - VIEW3D_OT_add_background_image -> VIEW3D_OT_background_image_add (same for remove) Also made 2 internal cmake vars hidden.
2010-12-08 11:42:11 +00:00
RNA_property_int_set(&but->rnapoin, prop, (int)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;
case PROP_FLOAT:
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00: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);
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
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);
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) {
style cleanup: interface
2012-03-30 01:51:25 +00: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
}
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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
float fval = (float)value;
if (fval >= -0.00001f && fval <= 0.00001f) fval = 0.0f; /* prevent negative zero */
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
}
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
/* then set value with possible edit override */
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->editval)
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *but->editval = 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_CHAR)
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *((char *)but->poin) = (char)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)
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *((short *)but->poin) = (short)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_INT)
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *((int *)but->poin) = (int)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_FLOAT)
style cleanup: interface
2012-03-30 01:51:25 +00:00
value = *((float *)but->poin) = (float)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
}
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
}
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_string_get_max_length(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
{
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
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;
else
return 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
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
{
uiBut *but_iter;
BLI_assert(but->flag & UI_BUT_DRAG_MULTI);
for (but_iter = but->block->buttons.first; but_iter; but_iter = but_iter->next) {
if (but_iter->editstr) {
break;
}
}
return but_iter;
}
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
/** \name Check to show extra icons
*
* Extra icons are shown on the right hand side of buttons.
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
* This could (should!) definitely become more generic, but for now this is good enough.
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
* \{ */
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
static bool ui_but_icon_extra_is_visible_text_clear(const uiBut *but)
{
BLI_assert(but->type == UI_BTYPE_TEXT);
Fix/cleanup stupid check on array of char being non-NULL pointer... Reported by coverity scan.
2017-01-20 18:43:42 +01:00
return ((but->flag & UI_BUT_VALUE_CLEAR) && but->drawstr[0]);
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
}
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
static bool ui_but_icon_extra_is_visible_search_unlink(const uiBut *but)
{
Workspaces: move delete to right click menu, instead of X on tab. These are not intended to be closed as often as e.g. browser tabs, they are intended to be more persistent and accidental closing should be avoided.
2018-08-23 19:58:54 +02:00
BLI_assert(ELEM(but->type, UI_BTYPE_SEARCH_MENU));
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
return ((but->editstr == NULL) &&
(but->drawstr[0] != '\0') &&
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
(but->flag & UI_BUT_VALUE_CLEAR));
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
}
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
static bool ui_but_icon_extra_is_visible_search_eyedropper(uiBut *but)
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
{
Correct crash in last commit (spacebar search)
2015-04-21 15:18:16 +10:00
StructRNA *type;
short idcode;
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
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
BLI_assert(but->type == UI_BTYPE_SEARCH_MENU && (but->flag & UI_BUT_VALUE_CLEAR));
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
Correct crash in last commit (spacebar search)
2015-04-21 15:18:16 +10:00
if (but->rnaprop == NULL) {
return false;
}
type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
idcode = RNA_type_to_ID_code(type);
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
return ((but->editstr == NULL) &&
(idcode == ID_OB || OB_DATA_SUPPORT_ID(idcode)));
}
uiButExtraIconType ui_but_icon_extra_get(uiBut *but)
{
UI: Add 'x' icon to text buttons to clear content This is useful e.g. for search buttons to quickly clear the filter string. We might want to make this optional for python scripts.
2016-11-28 18:59:31 +01:00
switch (but->type) {
case UI_BTYPE_TEXT:
if (ui_but_icon_extra_is_visible_text_clear(but)) {
return UI_BUT_ICONEXTRA_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 UI_BUT_ICONEXTRA_CLEAR;
}
else if (ui_but_icon_extra_is_visible_search_eyedropper(but)) {
return UI_BUT_ICONEXTRA_EYEDROPPER;
}
break;
default:
break;
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
}
return UI_BUT_ICONEXTRA_NONE;
}
/** \} */
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)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
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. */
Fix T41590: When scene scale is not 1.0, and units are "None," Blender assumes translations are in meters. Turned out there were several issues in handling of scale parameter by numinput. Fixed that by factorizing more some code in common with 'usual' numbuttons eval code (new `bUnit_getScaleUnit()` helper will return valid scaled value, depending on given system and type). Now, numinput behaves as expected - using default unit amended by scale in case no unit is given (i.e. entering '20' with a scale of 0.01 will give you 20cm, and '20cm' as well!).
2014-08-26 12:04:24 +02:00
if (unit_type == PROP_UNIT_TIME) { /* WARNING - using evil_C :| */
style cleanup: interface
2012-03-30 01:51:25 +00:00
Scene *scene = CTX_data_scene(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);
}
else {
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
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
}
}
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
/* str will be overwritten */
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_convert_to_unit_alt_name(uiBut *but, char *str, size_t maxlen)
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
{
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)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
int unit_type = UI_but_unit_type_get(but);
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
char *orig_str;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
UI: use BLI_strdup to store the original string.
2014-06-14 18:32:18 +10:00
orig_str = BLI_strdup(str);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
code cleanup: replace (val >> 16) with macro RNA_SUBTYPE_UNIT_VALUE(val)
2012-04-10 09:03:45 +00:00
bUnit_ToUnitAltName(str, maxlen, orig_str, unit->system, RNA_SUBTYPE_UNIT_VALUE(unit_type));
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
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
MEM_freeN(orig_str);
}
}
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(uiBut *but, char *str, int len_max, 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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
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;
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (unit->scale_length < 0.0001f) unit->scale_length = 1.0f; // XXX do_versions
- moved unit settings from user prefs into the scene. - use the scene context for the unit settings since there isn't a better place for it currently. - added 'chain' to imperial units - set more rna props to be distances and angles.
2009-08-13 07:37:41 +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
/* Use precision override? */
if (float_precision == -1) {
/* Sanity checks */
precision = (int)but->a2;
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
if (precision > UI_PRECISION_FLOAT_MAX) precision = UI_PRECISION_FLOAT_MAX;
Code cleanup: style
2014-04-20 22:05:05 +10:00
else if (precision == -1) precision = 2;
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;
}
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
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
bUnit_AsString2(
Cleanup: right shift in interface code
2018-07-01 19:57:31 +02:00
str, len_max, ui_get_but_scale_unit(but, value), precision,
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
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
{
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 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);
const double step = bUnit_ClosestScalar(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 */
if (step != -1.0) {
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_unit = ui_get_but_scale_unit(but, 1.0);
const double step_unit = bUnit_ClosestScalar(scale_unit, but->block->unit->system, unit_type);
double step_final;
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
BLI_assert(step > 0.0);
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: warnings - remove NULL checks for args already set as ATTR_NONNULL. - double promotion.
2015-10-17 16:06:45 +11:00
step_final = (step / scale_unit) / (double)UI_PRECISION_FLOAT_SCALE;
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
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;
}
return (float)step_final;
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +00:00
}
else {
return step_default;
}
}
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: For number buttons the precision to use or -1 to fallback to the button default.
* \param use_exp_float: Use exponent representation of floats when out of reasonable range (outside of 1e3/1e-3).
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
*/
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, const size_t maxlen, 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;
}
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)) {
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
PropertyType type;
add ENUM support for layout.prop_search() / uiItemPointerR
2012-11-24 05:15:48 +00:00
const char *buf = NULL;
py api - added PyC_UnicodeFromByteAndSize() to match PyUnicode_FromStringAndSize() also made RNA_property_string_get_alloc() return the length of the new string to avoid having to run strlen on it after.
2011-10-22 10:49:35 +00:00
int 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
type = RNA_property_type(but->rnaprop);
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
if ((but->type == UI_BTYPE_TAB) && (but->custom_data)) {
StructRNA *ptr_type = RNA_property_pointer_type(&but->rnapoin, but->rnaprop);
PointerRNA ptr;
/* uiBut.custom_data points to data this tab represents (e.g. workspace).
* uiBut.rnapoin/prop store an active value (e.g. active workspace). */
RNA_pointer_create(but->rnapoin.id.data, ptr_type, but->custom_data, &ptr);
buf = RNA_struct_name_get_alloc(&ptr, str, maxlen, &buf_len);
}
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
buf = RNA_property_string_get_alloc(&but->rnapoin, but->rnaprop, str, maxlen, &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 */
int value = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
if (RNA_property_enum_name(but->block->evil_C, &but->rnapoin, but->rnaprop, value, &buf)) {
BLI_strncpy(str, buf, maxlen);
buf = str;
}
}
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);
buf = RNA_struct_name_get_alloc(&ptr, str, maxlen, &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);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (!buf) {
[#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
}
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 (buf && buf != str) {
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
BLI_assert(maxlen <= 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 */
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
if (ui_but_is_utf8(but)) {
BLI_strncpy_utf8(str, buf, maxlen);
}
else {
BLI_strncpy(str, buf, maxlen);
}
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
}
}
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 */
BLI_strncpy(str, but->poin, maxlen);
return;
}
style cleanup
2012-10-14 13:08:19 +00:00
else if (ui_but_anim_expression_get(but, str, maxlen)) {
/* 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 */
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;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
value = ui_but_value_get(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
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);
}
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)) {
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
int prec = (float_precision == -1) ? ui_but_calc_float_precision(but, value) : float_precision;
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)) {
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
ui_get_but_string_unit(but, str, maxlen, value, false, prec);
}
else if (subtype == PROP_FACTOR) {
if (U.factor_display_type == USER_FACTOR_AS_FACTOR) {
BLI_snprintf(str, maxlen, "%.*f", prec, value);
}
else {
BLI_snprintf(str, maxlen, "%.*f", MAX2(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
}
use less verbose string formatting for units and interface.
2011-03-29 14:36:55 +00:00
else {
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
const int int_digits_num = integer_digits_f(value);
if (int_digits_num < -6 || int_digits_num > 12) {
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
BLI_snprintf(str, maxlen, "%.*g", prec, value);
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);
BLI_snprintf(str, maxlen, "%.*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
#if 0 /* TODO, but will likely break some stuff, so better after 2.79 release. */
prec -= int_digits_num;
CLAMP(prec, 0, UI_PRECISION_FLOAT_MAX);
#endif
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
BLI_snprintf(str, maxlen, "%.*f", prec, value);
}
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 {
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
BLI_snprintf(str, maxlen, "%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
}
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_string_get(uiBut *but, char *str, const size_t maxlen)
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
{
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_but_string_get_ex(but, str, maxlen, -1, false, NULL);
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
/**
* A version of #ui_but_string_get_ex for dynamic buffer sizes
* (where #ui_but_string_get_max_length returns 0).
*
* \param r_str_size: size of the returned string (including terminator).
*/
char *ui_but_string_get_dynamic(uiBut *but, int *r_str_size)
{
char *str = NULL;
*r_str_size = 1;
if (but->rnaprop && ELEM(but->type, UI_BTYPE_TEXT, UI_BTYPE_SEARCH_MENU)) {
PropertyType type;
type = RNA_property_type(but->rnaprop);
if (type == PROP_STRING) {
/* RNA string */
str = RNA_property_string_get_alloc(&but->rnapoin, but->rnaprop, NULL, 0, r_str_size);
(*r_str_size) += 1;
}
else if (type == PROP_ENUM) {
/* RNA enum */
int value = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
const char *value_id;
if (!RNA_property_enum_name(but->block->evil_C, &but->rnapoin, but->rnaprop, value, &value_id)) {
value_id = "";
}
*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);
str = RNA_struct_name_get_alloc(&ptr, NULL, 0, r_str_size);
(*r_str_size) += 1;
}
else {
BLI_assert(0);
}
}
else {
BLI_assert(0);
}
if (UNLIKELY(str == NULL)) {
/* should never happen, paranoid check */
*r_str_size = 1;
str = BLI_strdup("");
BLI_assert(0);
}
return str;
}
Cleanup: use return args last and 'r_' prefix.
2017-03-18 09:39:36 +11:00
static bool ui_set_but_string_eval_num_unit(bContext *C, uiBut *but, 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
{
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;
int type = RNA_SUBTYPE_UNIT_VALUE(UI_but_unit_type_get(but));
return user_string_to_number(C, str, unit, type, 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
{
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
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 BPY_execute_string_as_number(C, NULL, str, true, r_value);
#else
*r_value = atof(str);
return true;
#endif
}
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)
{
int len = strlen(str);
if (BLI_strn_endswith(str, "%", len)) {
char *str_new = BLI_strdupn(str, len - 1);
bool success = ui_number_from_string(C, str_new, r_value);
MEM_freeN(str_new);
*r_value /= 100.0;
return success;
}
else {
if (!ui_number_from_string(C, str, r_value)) {
return false;
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
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
}
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 true;
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
}
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)
{
int len = strlen(str);
if (BLI_strn_endswith(str, "%", len)) {
char *str_new = BLI_strdupn(str, len - 1);
bool success = ui_number_from_string(C, str_new, r_value);
MEM_freeN(str_new);
return success;
}
else {
return ui_number_from_string(C, str, r_value);
}
}
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
bool ui_but_string_set_eval_num(bContext *C, uiBut *but, const char *str, double *r_value)
{
if (str[0] == '\0') {
*r_value = 0.0;
return true;
}
building without python works again, cleanup bmesh include paths (cmake and scons).
2012-03-08 03:25:53 +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
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
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
if (ui_but_is_float(but)) {
if (ui_but_is_unit(but)) {
return ui_set_but_string_eval_num_unit(C, but, str, r_value);
}
else if (subtype == PROP_FACTOR) {
return ui_number_from_string_factor(C, str, r_value);
}
else if (subtype == PROP_PERCENTAGE) {
return ui_number_from_string_percentage(C, str, r_value);
}
else {
return ui_number_from_string(C, str, r_value);
}
}
else {
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 button string get/set into functions.
2015-01-06 11:05:08 +11:00
/* just the assignment/free part */
static void ui_but_string_set_internal(uiBut *but, const char *str, size_t str_len)
{
BLI_assert(str_len == strlen(str));
BLI_assert(but->str == NULL);
str_len += 1;
if (str_len > UI_MAX_NAME_STR) {
but->str = MEM_mallocN(str_len, "ui_def_but str");
}
else {
but->str = but->strdata;
}
memcpy(but->str, str, str_len);
}
static void ui_but_string_free_internal(uiBut *but)
{
if (but->str) {
if (but->str != but->strdata) {
MEM_freeN(but->str);
}
/* must call 'ui_but_string_set_internal' after */
but->str = NULL;
}
}
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)) {
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
PropertyType type;
style cleanup: interface
2012-03-30 01:51:25 +00:00
type = RNA_property_type(but->rnaprop);
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
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
}
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) {
Code Cleanup: remove redundant NULL checks and add function attributes
2014-01-20 11:13:53 +11:00
if (str[0] == '\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
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, PointerRNA_NULL);
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 * 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
else {
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
/* RNA pointer */
PointerRNA rptr;
PointerRNA ptr = but->rnasearchpoin;
PropertyRNA *prop = but->rnasearchprop;
Fix T59574: Prop_search fails to set objects from scene. Another case where editstr from search button would be used, when we actually have desired pointer itself already available in button. Am growing tired of doing bandaids fixes on that search menu stuff, whole thing would require some real re-coding imho, to get rid of that tantacular dependency over string 'identifier' only (when we should also have access to at the very least, the active index, and also probably active data pointer itself...). And/or clearly separate string identifier from 'UI' string shown to user.
2018-12-19 16:59:24 +01:00
/* This is kind of hackish, in theory think we could only ever use the second member of
* this if/else, since ui_searchbox_apply() is supposed to always set that pointer when
* 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.
* 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. */
if (prop && RNA_property_collection_lookup_string(&ptr, prop, str, &rptr)) {
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
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, rptr);
Fix T59574: Prop_search fails to set objects from scene. Another case where editstr from search button would be used, when we actually have desired pointer itself already available in button. Am growing tired of doing bandaids fixes on that search menu stuff, whole thing would require some real re-coding imho, to get rid of that tantacular dependency over string 'identifier' only (when we should also have access to at the very least, the active index, and also probably active data pointer itself...). And/or clearly separate string identifier from 'UI' string shown to user.
2018-12-19 16:59:24 +01:00
}
else if (but->func_arg2 != NULL) {
RNA_pointer_create(NULL, RNA_property_pointer_type(&but->rnapoin, but->rnaprop), but->func_arg2, &rptr);
RNA_property_pointer_set(&but->rnapoin, but->rnaprop, rptr);
}
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
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 * 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
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 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) {
int value;
if (RNA_property_enum_value(but->block->evil_C, &but->rnapoin, but->rnaprop, str, &value)) {
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
}
else {
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);
PointerRNA ptr;
PropertyRNA *prop;
/* uiBut.custom_data points to data this tab represents (e.g. workspace).
* uiBut.rnapoin/prop store an active value (e.g. active workspace). */
RNA_pointer_create(but->rnapoin.id.data, ptr_type, but->custom_data, &ptr);
prop = RNA_struct_name_property(ptr_type);
if (RNA_property_editable(&ptr, prop)) {
RNA_property_string_set(&ptr, prop, 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
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 = "";
}
else if (ui_but_is_utf8(but)) {
BLI_strncpy_utf8(but->poin, str, but->hardmax);
}
else {
BLI_strncpy(but->poin, str, but->hardmax);
}
minor changes to test editing - use BLI_strncpy_utf8 for utf8 buttons when pasting. - reuse code for ui_textedit_type_ascii / ui_textedit_type_utf8. - use memmove rather then for() loops in string editing. - merge jump/all arguments in interface_handlers.c into one enum arg.
2011-10-20 07:12:14 +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;
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] == '#') {
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
/* shortcut to create new driver expression (versus immediate Py-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;
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_string_set_eval_num(C, but, str, &value) == false) {
WM: remove unnecessary context argument from WM_report, no good reason to have it.
2016-01-16 21:51:05 +01:00
WM_report_banner_show();
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
}
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: 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);
}
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (value < (double)but->hardmin) value = but->hardmin;
if (value > (double)but->hardmax) value = but->hardmax;
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
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
}
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
}
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_default_set(bContext *C, const bool all, const bool use_afterfunc)
Durian request: Added 'Color Balance' node to compositor. uses Lift/Gamma/Gain similar to sequence editor. --> http://mke3.net/blender/devel/2.5/color_balance_node.jpg Also added 0 key (zero key) shortcut when mouse is over a button, to reset it to its default value. Same as the RMB menu ->Reset to Default, except for color wheels, it only resets the hue/sat/value components that that widget affects. Peter/Xavier: The existing color balance code can generate NaNs (fractional power of a negative), which causes havoc along the image pipeline. I added a check in the node code to prevent this. Still plenty of potential for lots of better colour correction tools in the compositor, just needs time...
2010-01-20 04:19:55 +00:00
{
Cleanup: Replace `WM_operator_name_call` by `WM_operator_name_call_ptr` where possible. This avoids one lookup in optypes list...
2014-11-16 11:09:51 +01:00
wmOperatorType *ot = WM_operatortype_find("UI_OT_reset_default_button", true);
Button value reset: * shortcut key changed from numpad 0 to delete. * fix missing undo push, now it calls the operator. Patch by Damir Prebeg, thanks!
2011-05-31 09:56:38 +00:00
Fix T37795: Resetting a button to the default value could crash Added ui_handle_afterfunc_add_operator so a button can queue an operator to run without executing it immediately.
2013-12-20 01:04:01 +11:00
if (use_afterfunc) {
PointerRNA *ptr;
ptr = ui_handle_afterfunc_add_operator(ot, WM_OP_EXEC_DEFAULT, true);
RNA_boolean_set(ptr, "all", all);
}
else {
PointerRNA ptr;
Cleanup: Replace `WM_operator_name_call` by `WM_operator_name_call_ptr` where possible. This avoids one lookup in optypes list...
2014-11-16 11:09:51 +01:00
WM_operator_properties_create_ptr(&ptr, ot);
Fix T37795: Resetting a button to the default value could crash Added ui_handle_afterfunc_add_operator so a button can queue an operator to run without executing it immediately.
2013-12-20 01:04:01 +11:00
RNA_boolean_set(&ptr, "all", all);
Cleanup: Replace `WM_operator_name_call` by `WM_operator_name_call_ptr` where possible. This avoids one lookup in optypes list...
2014-11-16 11:09:51 +01:00
WM_operator_name_call_ptr(C, ot, WM_OP_EXEC_DEFAULT, &ptr);
Fix T37795: Resetting a button to the default value could crash Added ui_handle_afterfunc_add_operator so a button can queue an operator to run without executing it immediately.
2013-12-20 01:04:01 +11:00
WM_operator_properties_free(&ptr);
}
Durian request: Added 'Color Balance' node to compositor. uses Lift/Gamma/Gain similar to sequence editor. --> http://mke3.net/blender/devel/2.5/color_balance_node.jpg Also added 0 key (zero key) shortcut when mouse is over a button, to reset it to its default value. Same as the RMB menu ->Reset to Default, except for color wheels, it only resets the hue/sat/value components that that widget affects. Peter/Xavier: The existing color balance code can generate NaNs (fractional power of a negative), which causes havoc along the image pipeline. I added a check in the node code to prevent this. Still plenty of potential for lots of better colour correction tools in the compositor, just needs time...
2010-01-20 04:19:55 +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
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 */
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (newmax * 0.2 >= max && newmax * 0.2 >= value)
return newmax * 0.2;
else if (newmax * 0.5 >= max && newmax * 0.5 >= value)
return newmax * 0.5;
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
else
return newmax;
}
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 */
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (newmax * 5.0 <= max && newmax * 5.0 <= value)
return newmax * 5.0;
else if (newmax * 2.0 <= max && newmax * 2.0 <= value)
return newmax * 2.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
else
return newmax;
}
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
/* note: this could be split up into functions which handle arrays and not */
static void ui_set_but_soft_range(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
{
Fix for [#34898] Typo in error message of mathutils.Vector * Also fixed some more cases of "more then" -> "more than".
2013-04-07 15:09:06 +00:00
/* ideally we would not limit this but practically, its more than
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
* enough worst case is very long vectors wont use a smart soft-range
spelling cleanup
2012-03-18 07:38:51 +00:00
* which isn't so bad. */
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
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 [#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
double softmin, softmax /*, step, precision*/;
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;
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 #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;
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;
style cleanup: also rename bmesh_decimate.c --> bmesh_decimate_collapse.c
2012-10-23 03:38:26 +00:00
/*step = istep;*/ /*UNUSED*/
/*precision = 1;*/ /*UNUSED*/
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
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);
style cleanup: interface
2012-03-30 01:51:25 +00: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 {
value_min = value_max = (double)RNA_property_int_get(&but->rnapoin, 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
}
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;
RNA_property_float_ui_range(&but->rnapoin, but->rnaprop, &fmin, &fmax, &fstep, &fprecision);
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = (fmin == -FLT_MAX) ? (float)-1e4 : fmin;
softmax = (fmax == FLT_MAX) ? (float)1e4 : fmax;
style cleanup: also rename bmesh_decimate.c --> bmesh_decimate_collapse.c
2012-10-23 03:38:26 +00:00
/*step = fstep;*/ /*UNUSED*/
/*precision = fprecision;*/ /*UNUSED*/
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
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
float value_range[2];
RNA_property_float_get_array_range(&but->rnapoin, but->rnaprop, value_range);
style cleanup: interface
2012-03-30 01:51:25 +00: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 {
value_min = value_max = (double)RNA_property_float_get(&but->rnapoin, 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
}
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
}
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) {
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 (value_min < 0.0)
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = -soft_range_round_up(-value_min, -softmin);
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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = soft_range_round_down(value_min, softmin);
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
if (softmin < (double)but->hardmin)
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmin = (double)but->hardmin;
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) {
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 (value_max < 0.0)
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = -soft_range_round_down(-value_max, -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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = soft_range_round_up(value_max, 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
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 (softmax > (double)but->hardmax)
style cleanup: interface
2012-03-30 01:51:25 +00:00
softmax = but->hardmax;
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
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
}
else {
BLI_assert(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
}
/* ******************* Free ********************/
2.5 Fix for the 'repeat last operator' option. It didn't work yet well outside editmode. Now undo/redo has to fully keep the UI alive, even when called from within a running popup. Another fix: when regions collapse/hide they were not effectively disabled, still accepting events. (like Nkey in 3d window).
2009-02-17 15:53:52 +00:00
/* can be called with C==NULL */
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
}
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: 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);
}
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
if (but->tip_argN) {
MEM_freeN(but->tip_argN);
}
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);
}
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->editstr && but->free_search_arg) {
MEM_SAFE_FREE(but->search_arg);
}
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 {
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) {
2.5 Fix for the 'repeat last operator' option. It didn't work yet well outside editmode. Now undo/redo has to fully keep the UI alive, even when called from within a running popup. Another fix: when regions collapse/hide they were not effectively disabled, still accepting events. (like Nkey in 3d window).
2009-02-17 15:53:52 +00: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
}
}
}
if (but->str && but->str != but->strdata) {
MEM_freeN(but->str);
2.5 Fix for the 'repeat last operator' option. It didn't work yet well outside editmode. Now undo/redo has to fully keep the UI alive, even when called from within a running popup. Another fix: when regions collapse/hide they were not effectively disabled, still accepting events. (like Nkey in 3d window).
2009-02-17 15:53:52 +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
if ((but->type == UI_BTYPE_IMAGE) && 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
IMB_freeImBuf((struct ImBuf *)but->poin);
}
image button was hard coded to draw the splash screen which it loaded from PNG data on every draw. now pass the ImBuf when callign the image button so we could have different images in buttons later on.
2011-09-17 16:57:37 +00:00
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if (but->dragpoin && (but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_freeN(but->dragpoin);
}
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(but);
}
2.5 Fix for the 'repeat last operator' option. It didn't work yet well outside editmode. Now undo/redo has to fully keep the UI alive, even when called from within a running popup. Another fix: when regions collapse/hide they were not effectively disabled, still accepting events. (like Nkey in 3d window).
2009-02-17 15:53:52 +00:00
/* can be called with C==NULL */
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
{
uiBut *but;
UI: butstore API to generalize button storage for modal handlers
2014-02-08 09:03:25 +11:00
UI_butstore_clear(block);
ghash/bli-listbase edits, rename BLI_ghash_pop -> BLI_ghash_popkey (since it takes a key as an arg and isnt popping any element from the hash as you might expect). add BLI_pophead/tail, since getting the first element from a list and removing it is a common task.
2013-08-26 23:37:08 +00:00
while ((but = 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) {
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
MEM_freeN(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
Context: Added a system for adding a "local" context in a UI layout. This way you can define for example within a modifier panel all operators to get the modifier in the context. In the layout code: uiLayoutSetContextPointer(layout, "modifier", &ptr) layout.set_context_pointer("modifier", md) In the operator: ptr = CTX_data_pointer_get(C, "modifier") md = context.modifier
2009-05-28 23:13:42 +00:00
CTX_store_free_list(&block->contexts);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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);
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
MEM_freeN(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_update_window_matrix(const bContext *C, const ListBase *lb)
{
ARegion *region = CTX_wm_region(C);
wmWindow *window = CTX_wm_window(C);
for (uiBlock *block = lb->first; block; block = block->next) {
if (block->active) {
ui_update_window_matrix(window, region, block);
}
}
}
void UI_blocklist_draw(const bContext *C, const ListBase *lb)
{
for (uiBlock *block = lb->first; block; block = block->next) {
if (block->active) {
UI_block_draw(C, block);
}
}
}
2.5 Fix for the 'repeat last operator' option. It didn't work yet well outside editmode. Now undo/redo has to fully keep the UI alive, even when called from within a running popup. Another fix: when regions collapse/hide they were not effectively disabled, still accepting events. (like Nkey in 3d window).
2009-02-17 15:53:52 +00:00
/* can be called with C==NULL */
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_blocklist_free(const bContext *C, 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
{
uiBlock *block;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
ghash/bli-listbase edits, rename BLI_ghash_pop -> BLI_ghash_popkey (since it takes a key as an arg and isnt popping any element from the hash as you might expect). add BLI_pophead/tail, since getting the first element from a list and removing it is a common task.
2013-08-26 23:37:08 +00:00
while ((block = 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
}
}
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_blocklist_free_inactive(const bContext *C, ListBase *lb)
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
{
uiBlock *block, *nextblock;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (block = lb->first; block; block = nextblock) {
nextblock = block->next;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 (!block->handle) {
if (!block->active) {
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
BLI_remlink(lb, block);
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);
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
}
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->active = 0;
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;
uiBlock *oldblock = NULL;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
oldblock = BLI_findstring(lb, block->name, offsetof(uiBlock, 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
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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
oldblock->active = 0;
oldblock->panel = NULL;
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
oldblock->handle = NULL;
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
}
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
uiBlock *UI_block_begin(const bContext *C, ARegion *region, const char *name, short dt)
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
{
uiBlock *block;
wmWindow *window;
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
Scene *scn;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
window = CTX_wm_window(C);
Changes to Color Management After testing and feedback, I've decided to slightly modify the way color management works internally. While the previous method worked well for rendering, was a smaller transition and had some advantages over this new method, it was a bit more ambiguous, and was making things difficult for other areas such as compositing. This implementation now considers all color data (with only a couple of exceptions such as brush colors) to be stored in linear RGB color space, rather than sRGB as previously. This brings it in line with Nuke, which also operates this way, quite successfully. Color swatches, pickers, color ramp display are now gamma corrected to display gamma so you can see what you're doing, but the numbers themselves are considered linear. This makes understanding blending modes more clear (a 0.5 value on overlay will not change the result now) as well as making color swatches act more predictably in the compositor, however bringing over color values from applications like photoshop or gimp, that operate in a gamma space, will give identical results. This commit will convert over existing files saved by earlier 2.5 versions to work generally the same, though there may be some slight differences with things like textures. Now that we're set on changing other areas of shading, this won't be too disruptive overall. I've made a diagram explaining the pipeline here: http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png and some docs here: http://www.blender.org/development/release-logs/blender-250/color-management/
2009-12-02 07:56:34 +00:00
scn = 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
block = MEM_callocN(sizeof(uiBlock), "uiBlock");
block->active = 1;
block->dt = dt;
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
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 (scn) {
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
*/
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
STRNCPY(block->display_device, scn->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
/* copy to avoid crash when scene gets deleted with ui still open */
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->unit = MEM_mallocN(sizeof(scn->unit), "UI UnitSettings");
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
memcpy(block->unit, &scn->unit, sizeof(scn->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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_strncpy(block->name, name, sizeof(block->name));
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 (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);
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 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_emboss_set(uiBlock *block, char dt)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->dt = dt;
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;
}
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)
{
size_t slen = 0;
STR_CONCAT(but->drawstr, slen, but->str);
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
if (value == (double)FLT_MAX) {
STR_CONCAT(but->drawstr, slen, "inf");
}
else if (value == (double)-FLT_MIN) {
STR_CONCAT(but->drawstr, slen, "-inf");
}
else if (subtype == PROP_PERCENTAGE) {
int prec = ui_but_calc_float_precision(but, value);
STR_CONCATF(but->drawstr, slen, "%.*f %%", prec, value);
}
else if (subtype == PROP_PIXEL) {
int prec = ui_but_calc_float_precision(but, value);
STR_CONCATF(but->drawstr, slen, "%.*f px", 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 if (subtype == PROP_FACTOR) {
int precision = ui_but_calc_float_precision(but, value);
if (U.factor_display_type == USER_FACTOR_AS_FACTOR) {
STR_CONCATF(but->drawstr, slen, "%.*f", precision, value);
}
else {
STR_CONCATF(but->drawstr, slen, "%.*f %%", MAX2(0, precision - 2), value * 100);
}
}
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)) {
char new_str[sizeof(but->drawstr)];
ui_get_but_string_unit(but, new_str, sizeof(new_str), value, true, -1);
STR_CONCAT(but->drawstr, slen, new_str);
}
else {
int prec = ui_but_calc_float_precision(but, value);
STR_CONCATF(but->drawstr, slen, "%.*f", prec, value);
}
}
static void ui_but_build_drawstr_int(uiBut *but, int value)
{
size_t slen = 0;
STR_CONCAT(but->drawstr, slen, but->str);
PropertySubType subtype = PROP_NONE;
if (but->rnaprop) {
subtype = RNA_property_subtype(but->rnaprop);
}
STR_CONCATF(but->drawstr, slen, "%d", value);
if (subtype == PROP_PERCENTAGE) {
STR_CONCAT(but->drawstr, slen, "%");
}
else if (subtype == PROP_PIXEL) {
STR_CONCAT(but->drawstr, slen, " px");
}
}
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;
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_select_flag(but, &value);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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)) {
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
if ((but->rnaprop != NULL) ||
(but->poin && (but->pointype & UI_BUT_POIN_TYPES)))
{
ui_set_but_soft_range(but);
}
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
}
Fix #21122: color sliders behaving weirdly.
2010-03-12 14:18: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
/* 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);
if (value < (double)but->hardmin) {
ui_but_value_set(but, but->hardmin);
}
else if (value > (double)but->hardmax) {
ui_but_value_set(but, but->hardmax);
}
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
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;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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:
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 == NULL) || (RNA_property_flag(but->rnaprop) & PROP_ICONS_CONSECUTIVE)) {
if (but->rnaprop && RNA_property_flag(but->rnaprop) & PROP_ICONS_REVERSE) {
but->drawflag |= UI_BUT_ICON_REVERSE;
}
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;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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
}
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
/* safety is 4 to enable small number buttons (like 'users') */
style cleanup: also rename bmesh_decimate.c --> bmesh_decimate_collapse.c
2012-10-23 03:38:26 +00:00
// okwidth = -4 + (BLI_rcti_size_x(&but->rect)); // UNUSED
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
/* name: */
style cleanup: interface
2012-03-30 01:51:25 +00:00
switch (but->type) {
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +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
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: shadowing (interface)
2015-11-23 10:01:54 +11:00
int value_enum = RNA_property_enum_get(&but->rnapoin, but->rnaprop);
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: unused args, indentation
2018-11-21 06:21:58 +11:00
but->block->evil_C,
&but->rnapoin, but->rnaprop, value_enum, &item))
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +11:00
{
Fix T47780: Icons don't update in floating panels
2016-03-15 21:12:37 +11:00
size_t slen = strlen(item.name);
UI: refactor button string get/set into functions.
2015-01-06 11:05:08 +11:00
ui_but_string_free_internal(but);
Fix T47780: Icons don't update in floating panels
2016-03-15 21:12:37 +11:00
ui_but_string_set_internal(but, item.name, slen);
but->icon = item.icon;
Fix T38706: dropdown labels in popups not updating Caused by own recent changes to menu handling
2014-02-19 11:30:06 +11:00
}
}
}
BLI_strncpy(but->drawstr, but->str, sizeof(but->drawstr));
}
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_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 {
ui_but_build_drawstr_int(but, (int)value);
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
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)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
int prec;
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);
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
prec = ui_but_calc_float_precision(but, value);
style cleanup: interface
2012-03-30 01:51:25 +00:00
BLI_snprintf(but->drawstr, sizeof(but->drawstr), "%s%.*f", but->str, prec, value);
}
else {
BLI_strncpy(but->drawstr, but->str, UI_MAX_DRAW_STR);
}
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
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
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];
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_string_get(but, str, UI_MAX_DRAW_STR);
style cleanup: interface
2012-03-30 01:51:25 +00:00
BLI_snprintf(but->drawstr, sizeof(but->drawstr), "%s%s", but->str, str);
}
break;
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
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) {
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
str = "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);
UI: add ability to access/generate 'shortcuts strings' of modal keymaps. We already had that for global keymaps (used e.g. to generate shortcuts for menu entries), but this wasn’t possible for modal keymaps yet (e.g. help message in header during transforms and other modal operation). This commit only adds needing background code, it does not change anything from user PoV. Modal operators will be updated to use it in comming weeks. Thanks to Campbell for revisions & suggestions. :) Differential Revision: https://developer.blender.org/D780
2015-07-03 15:07:46 +02:00
str = WM_key_event_string((short)value, false);
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
BLI_snprintf(but->drawstr, UI_MAX_DRAW_STR, "%s%s", 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) {
if (but->modifier_key) {
char *str = but->drawstr;
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
but->drawstr[0] = '\0';
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->modifier_key & KM_SHIFT)
add BLI_strcpy_rlen, replace strcat, which was used in misleading way.
2013-06-16 08:29:02 +00:00
str += BLI_strcpy_rlen(str, "Shift ");
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->modifier_key & KM_CTRL)
add BLI_strcpy_rlen, replace strcat, which was used in misleading way.
2013-06-16 08:29:02 +00:00
str += BLI_strcpy_rlen(str, "Ctrl ");
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->modifier_key & KM_ALT)
add BLI_strcpy_rlen, replace strcat, which was used in misleading way.
2013-06-16 08:29:02 +00:00
str += BLI_strcpy_rlen(str, "Alt ");
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (but->modifier_key & KM_OSKEY)
add BLI_strcpy_rlen, replace strcat, which was used in misleading way.
2013-06-16 08:29:02 +00:00
str += BLI_strcpy_rlen(str, "Cmd ");
style cleanup: interface
2012-03-30 01:51:25 +00:00
(void)str; /* UNUSED */
}
ui: internal change. replace strcat with BLI string functions for key-event drawing.
2013-07-25 13:18:11 +00:00
else {
BLI_strncpy(but->drawstr, "Press a key", UI_MAX_DRAW_STR);
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
}
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
BLI_strncpy(but->drawstr, but->str, UI_MAX_DRAW_STR);
break;
Key Configuration Keymaps are now saveable and configurable from the user preferences, note that editing one item in a keymap means the whole keymap is now defined by the user and will not be updated by Blender, an option for syncing might be added later. The outliner interface is still there, but I will probably remove it. There's actually 3 levels now: * Default builtin key configuration. * Key configuration loaded from .py file, for configs like Blender 2.4x or other 3D applications. * Keymaps edited by the user and saved in .B.blend. These can be saved to .py files as well to make creating distributable configurations easier. Also, user preferences sections were reorganized a bit, now there is: Interface, Editing, Input, Files and System. Implementation notes: * wmKeyConfig was added which represents a key configuration containing keymaps. * wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap. * Modal maps are not wrapped yet. * User preferences DNA file reading did not support newdataadr() yet, added this now for reading keymaps. * Key configuration related settings are now RNA wrapped. * is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +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_HSVCUBE:
case UI_BTYPE_HSVCIRCLE:
style cleanup: interface
2012-03-30 01:51:25 +00:00
break;
default:
BLI_strncpy(but->drawstr, but->str, UI_MAX_DRAW_STR);
code cleanup: add break statements in switch ()'s, (even at the last case).
2013-07-21 08:16:37 +00:00
break;
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
}
/* if we are doing text editing, this will override the drawstr */
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->editstr)
UI: more changes for large textfields - no longer set 'but->drawstr' when editing buttons. - clip text and set cursor based on the 'editstr'.
2014-05-03 09:18:00 +10:00
but->drawstr[0] = '\0';
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 */
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 (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++;
/* buttons declared after this call will get this align nr */ // 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
}
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
struct 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
{
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
struct 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: 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
static uiBut *ui_but_alloc(const eButType type)
{
switch (type) {
case UI_BTYPE_TAB:
return MEM_callocN(sizeof(uiButTab), "uiButTab");
default:
return MEM_callocN(sizeof(uiBut), "uiBut");
}
}
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
/**
* \brief ui_def_but is the function that draws many button types
*
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.
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
*
correct indentation and some whitespace edits (no functional changes)
2011-11-11 13:09:14 +00:00
* for float buttons:
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* \param a1: Click Step (how much to change the value each click)
* \param a2: Number of decimal point values to display. 0 defaults to 3 (0.000)
* 1,2,3, and a maximum of 4, all greater values will be clamped to 4.
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, const char *str,
int x, int y, short width, short height,
void *poin, float min, float max, float a1, float a2, 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
{
uiBut *but;
use BLI_strnlen rather then strlen when comparing against fixed lengths.
2010-12-05 23:50:55 +00:00
int slen;
code cleanup: correct misleading use of LABEL button type.
2012-09-14 05:44:47 +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
BLI_assert(width >= 0 && height >= 0);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
code cleanup: correct misleading use of LABEL button type.
2012-09-14 05:44:47 +00:00
/* we could do some more error checks 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 & BUTTYPE) == UI_BTYPE_LABEL) {
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
BLI_assert((poin != NULL || min != 0.0f || max != 0.0f || (a1 == 0.0f && a2 != 0.0f) || (a1 != 0.0f && a1 != 1.0f)) == false);
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 */
if (poin == NULL) {
BLI_assert(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
return NULL;
code cleanup: correct misleading use of LABEL button type.
2012-09-14 05:44:47 +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: 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
but = ui_but_alloc(type & BUTTYPE);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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->type = type & BUTTYPE;
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->pointype = type & UI_BUT_POIN_TYPES;
but->bit = type & UI_BUT_POIN_BIT;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->bitnr = type & 31;
minor changes, dont append with cmake platform flags which is a string and use enum values rather then ints in a few places.
2011-09-30 15:22:13 +00:00
but->icon = ICON_NONE;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->iconadd = 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->retval = retval;
use BLI_strnlen rather then strlen when comparing against fixed lengths.
2010-12-05 23:50:55 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
slen = strlen(str);
UI: refactor button string get/set into functions.
2015-01-06 11:05:08 +11:00
ui_but_string_set_internal(but, str, slen);
use BLI_strnlen rather then strlen when comparing against fixed lengths.
2010-12-05 23:50:55 +00: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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->poin = poin;
but->hardmin = but->softmin = min;
but->hardmax = but->softmax = max;
but->a1 = a1;
but->a2 = a2;
but->tip = 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
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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dt = block->dt;
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
but->pie_dir = UI_RADIAL_NONE;
style cleanup: interface
2012-03-30 01:51:25 +00:00
style cleanup
2012-08-19 10:41:27 +00:00
but->block = block; /* pointer back, used for frontbuffer status, and picker */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 ((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;
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
but->func = block->func;
but->func_arg1 = block->func_arg1;
but->func_arg2 = block->func_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 cleanup: interface
2012-03-30 01:51:25 +00:00
but->funcN = block->funcN;
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->func_argN)
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func_argN = MEM_dupallocN(block->func_argN);
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
but->pos = -1; /* cursor invisible */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if (ELEM(but->type, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER)) { /* add a space to name */
minor edits - use TRUE/FALSE rather than 1/0 - WM_operator_properties_create_ptr rather than WM_operator_properties_create since the pointers available. - remove redundant strlen()
2011-10-05 12:20:38 +00:00
/* slen remains unchanged from previous assignment, ensure this stays true */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (slen > 0 && slen < UI_MAX_NAME_STR - 2) {
if (but->str[slen - 1] != ' ') {
but->str[slen] = ' ';
but->str[slen + 1] = 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
}
}
}
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;
Fix T56898: misaligned icons in buttons in popovers.
2018-10-11 17:42:50 +02:00
if (but->str && but->str[0]) {
Fix: Icon alignment for scaled pie buttons with no text
2017-06-20 20:15:04 +03:00
but->drawflag |= UI_BUT_ICON_LEFT;
Fix T56898: misaligned icons in buttons in popovers.
2018-10-11 17:42:50 +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
}
Fix misaligned icon in search buttons after recent changes.
2018-10-12 15:55:36 +02:00
else if (((block->flag & UI_BLOCK_LOOP) && !ui_block_is_popover(block)) ||
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_PROGRESS_BAR, UI_BTYPE_POPOVER))
style cleanup
2012-07-21 16:21:42 +00:00
{
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)) {
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
if (slen != 0) {
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: 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
}
Bugfix #25652 Report was that move-to-layer menu failed. The real cause was more complex; had to dive deep in the dungeons of the interface code that handled undos and operators. Found several issues: - popup menus (like redo operator, color picker) executed again on a mouse-exit - far too many buttons were sending undo pushes; even worse, in the operator redo-panel each button action was pushed twice - in case operator redo-buttons have own callbacks (like layer buttons) the redo wasn't working - layerbutton menu was called without creating a proper undo/redo case Things should all work smoother now! On todo: - better definition and handling of all versions for operator menus (four types now, not fun) also: make operator "do" menu, which on first action does operator and then switches to redo-ing - bring back Undo menu, to list the undo stack and jump in it.
2011-01-19 14:19:20 +00:00
/* keep track of UI_interface.h */
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_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;
}
2.5 Bugfixes #19302: the spin operator did not redo correct when changing properties. Actually the problem was somewhere else, the search menu always did an unnecessary undo push, which conflicted with an operator undo push with the same name. Only in the case of "Spin" was this noticed, because it's name is so short and you actually type it completely. #19328: swapping areas could crash when dragging mouse outside the window. Attempted fix for #19331, #19335 as well, where backspace and some other keys give square characters instead of working as expected. Couldn't reproducable here, so please test.
2009-09-14 20:48:05 +00:00
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);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +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 (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);
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
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 the 'UI_OT_editsource' is running, extract the source info from the button */
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;
}
Cleanup: style
2015-05-13 06:10:49 +10:00
void ui_def_but_icon(uiBut *but, const int icon, const int flag)
{
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) {
ui_icon_ensure_deferred(but->block->evil_C, icon, (flag & UI_BUT_ICON_PREVIEW) != 0);
}
but->icon = (BIFIconID)icon;
but->flag |= flag;
if (but->str && but->str[0]) {
but->drawflag |= UI_BUT_ICON_LEFT;
}
}
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 void ui_def_but_rna__disable(uiBut *but, const char *info)
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
{
but->flag |= UI_BUT_DISABLED;
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
but->disabled_info = info;
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: 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
static void ui_def_but_rna__menu(bContext *UNUSED(C), uiLayout *layout, void *but_p)
{
uiBlock *block = uiLayoutGetBlock(layout);
uiPopupBlockHandle *handle = block->handle;
uiBut *but = (uiBut *)but_p;
/* see comment in ui_item_enum_expand, re: uiname */
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
const EnumPropertyItem *item, *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
bool free;
uiLayout *split, *column = NULL;
int totitems = 0;
int columns, rows, a, b;
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
int column_end = 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
int nbr_entries_nosepr = 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
UI_block_flag_enable(block, UI_BLOCK_MOVEMOUSE_QUIT);
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
RNA_property_enum_items_gettexted(block->evil_C, &but->rnapoin, but->rnaprop, &item_array, NULL, &free);
/* we dont 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);
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
for (item = item_array; item->identifier; item++, totitems++) {
if (!item->identifier[0]) {
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
/* inconsistent, but menus with categories do not look good flipped */
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->name) {
block->flag |= UI_BLOCK_NO_FLIP;
nbr_entries_nosepr++;
}
/* We do not want simple separators in nbr_entries_nosepr count */
continue;
}
nbr_entries_nosepr++;
}
/* Columns and row estimation. Ignore simple separators here. */
columns = (nbr_entries_nosepr + 20) / 20;
if (columns < 1)
columns = 1;
if (columns > 8)
columns = (nbr_entries_nosepr + 25) / 25;
rows = totitems / columns;
if (rows < 1)
rows = 1;
while (rows * columns < totitems)
rows++;
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
if (block->flag & UI_BLOCK_NO_FLIP) {
/* Title at the top for menus with categories. */
uiDefBut(block, UI_BTYPE_LABEL, 0, RNA_property_ui_name(but->rnaprop),
0, 0, UI_UNIT_X * 5, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
uiItemS(layout);
}
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
/* note, item_array[...] is reversed on access */
/* create items */
split = uiLayoutSplit(layout, 0.0f, false);
for (a = 0; a < totitems; a++) {
if (a == column_end) {
/* 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;
for (b = a + 1; b < totitems; b++) {
Code cleanup: style
2014-04-20 22:05:05 +10:00
item = &item_array[b];
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 */
if (((b - a) % rows == 0) || (!item->identifier[0] && item->name)) {
column_end = b;
break;
}
}
column = uiLayoutColumn(split, false);
}
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
item = &item_array[a];
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]) {
if (item->name) {
if (item->icon) {
uiItemL(column, item->name, item->icon);
}
else {
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* Do not use uiItemL here, as our root layout is a menu one,
* it will add a fake blank icon! */
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
uiDefBut(block, UI_BTYPE_LABEL, 0, item->name, 0, 0, UI_UNIT_X * 5, UI_UNIT_Y, NULL, 0.0, 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
}
}
else {
uiItemS(column);
}
}
else {
if (item->icon) {
Cleanup: right shift in interface code
2018-07-01 19:57:31 +02:00
uiDefIconTextButI(
block, UI_BTYPE_BUT_MENU, B_NOP, item->icon, item->name, 0, 0,
UI_UNIT_X * 5, UI_UNIT_Y, &handle->retvalue, item->value, 0.0, 0, -1, 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 {
Cleanup: right shift in interface code
2018-07-01 19:57:31 +02:00
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, 0, -1, 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
}
}
}
Fix T62216: order of items flipped in some menus like object mode.
2019-03-05 14:35:52 +01:00
if (!(block->flag & UI_BLOCK_NO_FLIP)) {
/* Title at the bottom for menus without categories. */
uiItemS(layout);
uiDefBut(block, UI_BTYPE_LABEL, 0, RNA_property_ui_name(but->rnaprop),
0, 0, UI_UNIT_X * 5, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 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
UI_block_layout_set_current(block, layout);
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
}
UI: cleanup next/prev order in menu code Recent flag re-order broke it since bits overlap, but logic here was far too complicated & fragile, Checked the type of each button when testing which direction to handle events as well as block direction. Now store the block-flipped state as a flag.
2014-11-15 14:32:23 +01:00
BLI_assert((block->flag & UI_BLOCK_IS_FLIP) == 0);
block->flag |= UI_BLOCK_IS_FLIP;
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: 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 then 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, float a1, float a2, 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: 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
uiBut *but;
UI: remove unused freestr
2014-02-13 09:49:00 +11:00
int icon = 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
uiMenuCreateFunc func = NULL;
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 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);
}
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_BTYPE_MENU is handled a little differently here */
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
const EnumPropertyItem *item;
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
int value;
bool free;
int i;
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
RNA_property_enum_items(block->evil_C, ptr, prop, &item, NULL, &free);
Code cleanup: UI - de-duplicate menu/row/listrow enum logic
2014-03-12 19:11:09 +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
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 {
value = (int)max;
}
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
i = RNA_enum_from_value(item, value);
if (i != -1) {
RNA * Enums can now be dynamically created in the _itemf callback, using RNA_enum_item(s)_add, RNA_enum_item_end. All places asking for enum items now need to potentially free the items. * This callback now also gets context, this was added specifically for operators. This doesn't fit design well at all, needed to do some ugly hacks, but can't find a good solution at the moment. * All enums must have a default list of items too, even with an _itemf callback, for docs and fallback in case there is no context. * Used by MESH_OT_merge, MESH_OT_select_similar, TFM_OT_select_orientation. * Also changes some operator properties that were enums to booleas (unselected, deselect), to make them consistent with other ops.
2009-07-10 19:56:13 +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
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
}
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 = item[i].icon;
}
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);
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
}
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: 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
}
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 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;
}
Code cleanup: UI - de-duplicate menu/row/listrow enum logic
2014-03-12 19:11:09 +11: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);
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
}
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
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 (!tip && proptype != PROP_ENUM)
style cleanup: interface
2012-03-30 01:51:25 +00:00
tip = RNA_property_ui_description(prop);
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (min == max || a1 == -1 || a2 == -1) {
if (proptype == PROP_INT) {
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
int hardmin, hardmax, softmin, softmax, step;
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
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
RNA_property_int_range(ptr, prop, &hardmin, &hardmax);
RNA_property_int_ui_range(ptr, prop, &softmin, &softmax, &step);
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_ROW, UI_BTYPE_LISTROW) && min == max) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
min = hardmin;
max = hardmax;
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
}
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 (a1 == -1)
style cleanup: interface
2012-03-30 01:51:25 +00:00
a1 = step;
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 (a2 == -1)
style cleanup: interface
2012-03-30 01:51:25 +00:00
a2 = 0;
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
}
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 (proptype == PROP_FLOAT) {
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
float hardmin, hardmax, softmin, softmax, step, precision;
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
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
RNA_property_float_range(ptr, prop, &hardmin, &hardmax);
RNA_property_float_ui_range(ptr, prop, &softmin, &softmax, &step, &precision);
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
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_ROW, UI_BTYPE_LISTROW) && min == max) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
min = hardmin;
max = hardmax;
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (a1 == -1)
style cleanup: interface
2012-03-30 01:51:25 +00:00
a1 = step;
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 (a2 == -1)
style cleanup: interface
2012-03-30 01:51:25 +00:00
a2 = precision;
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
}
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 (proptype == PROP_STRING) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
min = 0;
max = RNA_property_string_maxlength(prop);
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
/* note, 'max' may be zero (code for dynamically resized array) */
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
}
collection attributes can now be resolved with by rna this now works... bpy.context.scene.path_resolve("objects.active.location") Also added an option to coerce the property into a native pytype.
2010-08-23 05:36:21 +00: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
/* now create button */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but(block, type, retval, str, x, y, width, height, NULL, min, max, a1, a2, tip);
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->rnapoin = *ptr;
but->rnaprop = prop;
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
replace RNA_property_array_length with RNA_property_array_check where the length of the array is only used to check if the property is an array or not. (this isnt reliable since arrays can be zero length).
2013-09-16 01:35:52 +00:00
if (RNA_property_array_check(but->rnaprop))
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->rnaindex = index;
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->rnaindex = 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
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);
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: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Fix T54580: Pointer buttons skip undo push
2018-12-03 18:43:33 +11:00
if (type == UI_BTYPE_MENU) {
if (but->dt == UI_EMBOSS_PULLDOWN) {
Merge branch 'master' into blender2.8
2018-12-03 19:31:54 +11:00
ui_but_submenu_enable(block, but);
Fix T54580: Pointer buttons skip undo push
2018-12-03 18:43:33 +11:00
}
}
else if (type == UI_BTYPE_SEARCH_MENU) {
if (proptype == PROP_POINTER) {
/* Search buttons normally don't get undo, see: T54580. */
but->flag |= UI_BUT_UNDO;
}
UI: Fix for rna-enum submenus not showing a right arrow
2014-02-20 13:30:52 +11: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
const char *info;
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->rnapoin.data && !RNA_property_editable_info(&but->rnapoin, prop, &info)) {
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
ui_def_but_rna__disable(but, info);
* Added support for displaying disabled RNA buttons The functionality already existed via the RNA system, this commit makes disabled buttons draw greyed out, and not respond to clicks (previously, they would drag/edit/etc but then reset to the previous value)
2009-01-04 02:09:41 +00: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 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->flag & UI_BUT_UNDO && (ui_but_is_rna_undo(but) == false)) {
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
but->flag &= ~UI_BUT_UNDO;
disable undo for screen & wm RNA buttons, changing shading mode via the UI for eg was doing an undo push.
2011-08-18 16:26:34 +00: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)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->a1 = ui_get_but_step_unit(but, but->a1);
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
}
Set the clickstep for unit buttons to each click moves 1 unit.
2009-08-12 08:16:10 +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
if (func) {
but->menu_create_func = func;
but->poin = (char *)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
static uiBut *ui_def_but_rna_propname(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, float a1, float a2, const char *tip)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
PropertyRNA *prop = RNA_struct_find_property(ptr, propname);
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
uiBut *but;
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 (prop) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna(block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, a1, a2, tip);
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 {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but(block, type, retval, propname, x, y, width, height, NULL, min, max, a1, a2, tip);
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
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
ui_def_but_rna__disable(but, "Unknown Property.");
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
}
return but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
static uiBut *ui_def_but_operator_ptr(uiBlock *block, int type, wmOperatorType *ot, int opcontext, const char *str, 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
{
uiBut *but;
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 (!str) {
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
if (ot && ot->srna)
str = RNA_struct_ui_name(ot->srna);
else
str = "";
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
}
Fixing issues with i18n stuff: - Make gettext stuff draw-time. so switching between languages can happens without restart now. - Added option to translate visible interface (menus, buttons, labels) and tooltips. Now it's possible to have english UI and localized tooltips. - Clean-up sources, do not use gettext stuff for things which can be collected with RNA. - Fix issues with windows 64bit and ru_RU locale on my desktop (it was codepage issue). - Added operator "Get Messages" which generates new text block with with all strings collected from RNA. - Changed script for updating blender.pot so now it appends messages collected from rna to automatically gathered messages. To update .pot you have to re-generate messages.txt using "Get Messages" operator and then run update_pot script. - Clean up old translation stuff which wasn't used and most probably wouldn't be used. - Return back "International Fonts" option, so if it's disabled, no gettext lookups happens on draw. - Merged read_homefile function back. No need in splitting it. TODO: - Custom fonts and font size. Current font isn't nice at least for russian locale, it's difficult to read it. - Put references to messages.txt so gettext can merge translation when name/description of some property changes.
2011-09-15 13:20:18 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if ((!tip || tip[0] == '\0') && ot && ot->srna) {
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
}
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
but = ui_def_but(block, type, -1, str, x, y, width, height, NULL, 0, 0, 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 */
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!ot) {
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
but->flag |= UI_BUT_DISABLED;
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 = "";
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
}
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;
}
Quiet warnings about unused functions and variables. Commented or '#if 0' these functions/variables and marked with 'UNUSED' comment so they can be restored in the future if needed.
2012-03-19 22:21:40 +00: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, const char *str, int x, int y, short width, short height, void *poin, float min, float max, float a1, float a2, 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: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *but = ui_def_but(block, type, retval, str, x, y, width, height, poin, min, max, a1, a2, 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
ui_but_update(but);
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 but;
}
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
}
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
int idx = 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: unnecessary comma use
2016-03-05 09:09:05 +11: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; }
if (x & 0x2) { idx += 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
return idx;
}
}
/* autocomplete helper functions */
struct AutoComplete {
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
size_t maxlen;
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
};
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
AutoComplete *UI_autocomplete_begin(const char *startname, size_t maxlen)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
autocpl = MEM_callocN(sizeof(AutoComplete), "AutoComplete");
autocpl->maxlen = maxlen;
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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
autocpl->truncate = MEM_callocN(sizeof(char) * maxlen, "AutoCompleteTruncate");
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;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
int a;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < autocpl->maxlen - 1; a++) {
if (startname[a] == 0 || startname[a] != name[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;
}
/* found a match */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (startname[a] == 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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (truncate[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
BLI_strncpy(truncate, name, autocpl->maxlen);
else {
/* remove from truncate what is not in bone->name */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < autocpl->maxlen - 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;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (truncate[a] != name[a])
truncate[a] = 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
}
}
}
}
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;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_strncpy(autoname, autocpl->truncate, autocpl->maxlen);
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 {
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 (autoname != autocpl->startname) { /* don't copy a string over its self */
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
BLI_strncpy(autoname, autocpl->startname, autocpl->maxlen);
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
}
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
}
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
}
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, const char *str, int x, int y, short width, short height, void *poin, float min, float max, float a1, float a2, 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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
int bitIdx = findBitIndex(bit);
if (bitIdx == -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
return NULL;
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 {
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_BIT | bitIdx, retval, str, x, y, width, height, poin, min, max, a1, a2, 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, const char *str, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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, a1, a2, 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 *uiDefButBitF(uiBlock *block, int type, int bit, int retval, const char *str, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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_FLOAT, bit, retval, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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, const char *str, int x, int y, short width, short height, int *poin, float min, float max, float a1, float a2, 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, a1, a2, 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, const char *str, int x, int y, short width, short height, int *poin, float min, float max, float a1, float a2, 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, a1, a2, 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, const char *str, int x, int y, short width, short height, short *poin, float min, float max, float a1, float a2, 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, a1, a2, 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, const char *str, int x, int y, short width, short height, short *poin, float min, float max, float a1, float a2, 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, a1, a2, 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, const char *str, int x, int y, short width, short height, char *poin, float min, float max, float a1, float a2, 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, min, max, a1, a2, 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 *uiDefButBitC(uiBlock *block, int type, int bit, int retval, const char *str, int x, int y, short width, short height, char *poin, float min, float max, float a1, float a2, 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_CHAR, bit, retval, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *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, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna_propname(block, type, retval, str, x, y, width, height, ptr, propname, index, min, max, a1, a2, 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);
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
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, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna(block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, a1, a2, 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;
}
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30:07 +00: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, int opcontext, const char *str, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
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, int opcontext, 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
{
wmOperatorType *ot = WM_operatortype_find(opname, 0);
if (str == NULL && ot == NULL) 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
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
/* if a1==1.0 then a2 is an extra icon blending factor (alpha 0.0 - 1.0) */
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, float a1, float a2, 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: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *but = ui_def_but(block, type, retval, "", x, y, width, height, poin, min, max, a1, a2, 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, float a1, float a2, 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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
int bitIdx = findBitIndex(bit);
if (bitIdx == -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
return NULL;
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 {
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_BIT | bitIdx, retval, icon, x, y, width, height, poin, min, max, a1, a2, 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 *uiDefIconButF(uiBlock *block, int type, int retval, int icon, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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_FLOAT, retval, icon, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconButBitF(uiBlock *block, int type, int bit, int retval, int icon, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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_FLOAT, bit, retval, icon, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconButI(uiBlock *block, int type, int retval, int icon, int x, int y, short width, short height, int *poin, float min, float max, float a1, float a2, 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, a1, a2, 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, float a1, float a2, 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, a1, a2, 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, float a1, float a2, 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, a1, a2, 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, float a1, float a2, 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, a1, a2, 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 *uiDefIconButC(uiBlock *block, int type, int retval, int icon, int x, int y, short width, short height, char *poin, float min, float max, float a1, float a2, 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_CHAR, retval, icon, x, y, width, height, (void *) poin, min, max, a1, a2, 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, float max, float a1, float a2, 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_CHAR, bit, retval, icon, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *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, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna_propname(block, type, retval, "", x, y, width, height, ptr, propname, index, min, max, a1, a2, 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);
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
return but;
}
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, int retval, int icon, int x, int y, short width, short height, PointerRNA *ptr, PropertyRNA *prop, int index, float min, float max, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna(block, type, retval, "", x, y, width, height, ptr, prop, index, min, max, a1, a2, 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;
}
reduce operator lookups in the UI (could do 4 hash lookups per button).
2012-01-22 03:30:07 +00: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, int opcontext, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
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, int opcontext, 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
{
wmOperatorType *ot = WM_operatortype_find(opname, 0);
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
/* Button containing both string label and icon */
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, const char *str, int x, int y, short width, short height, void *poin, float min, float max, float a1, float a2, 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: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *but = ui_def_but(block, type, retval, str, x, y, width, height, poin, min, max, a1, a2, 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
static uiBut *uiDefIconTextButBit(uiBlock *block, int type, int bit, int retval, int icon, const char *str, int x, int y, short width, short height, void *poin, float min, float max, float a1, float a2, 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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
int bitIdx = findBitIndex(bit);
if (bitIdx == -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
return NULL;
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 {
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_BIT | bitIdx, retval, icon, str, x, y, width, height, poin, min, max, a1, a2, 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 *uiDefIconTextButF(uiBlock *block, int type, int retval, int icon, const char *str, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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_FLOAT, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButBitF(uiBlock *block, int type, int bit, int retval, int icon, const char *str, int x, int y, short width, short height, float *poin, float min, float max, float a1, float a2, 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 uiDefIconTextButBit(block, type | UI_BUT_POIN_FLOAT, bit, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButI(uiBlock *block, int type, int retval, int icon, const char *str, int x, int y, short width, short height, int *poin, float min, float max, float a1, float a2, 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, a1, a2, 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 *uiDefIconTextButBitI(uiBlock *block, int type, int bit, int retval, int icon, const char *str, int x, int y, short width, short height, int *poin, float min, float max, float a1, float a2, 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 uiDefIconTextButBit(block, type | UI_BUT_POIN_INT, bit, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButS(uiBlock *block, int type, int retval, int icon, const char *str, int x, int y, short width, short height, short *poin, float min, float max, float a1, float a2, 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_SHORT, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButBitS(uiBlock *block, int type, int bit, int retval, int icon, const char *str, int x, int y, short width, short height, short *poin, float min, float max, float a1, float a2, 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 uiDefIconTextButBit(block, type | UI_BUT_POIN_SHORT, bit, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButC(uiBlock *block, int type, int retval, int icon, const char *str, int x, int y, short width, short height, char *poin, float min, float max, float a1, float a2, 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_CHAR, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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 *uiDefIconTextButBitC(uiBlock *block, int type, int bit, int retval, int icon, const char *str, int x, int y, short width, short height, char *poin, float min, float max, float a1, float a2, 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 uiDefIconTextButBit(block, type | UI_BUT_POIN_CHAR, bit, retval, icon, str, x, y, width, height, (void *) poin, min, max, a1, a2, 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, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna_propname(block, type, retval, str, x, y, width, height, ptr, propname, index, min, max, a1, a2, 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;
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
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, float a1, float a2, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
but = ui_def_but_rna(block, type, retval, str, x, y, width, height, ptr, prop, index, min, max, a1, a2, 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 *uiDefIconTextButO_ptr(uiBlock *block, int type, wmOperatorType *ot, int opcontext, int icon, const char *str, 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
{
uiBut *but;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
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, int opcontext, int icon, 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
{
wmOperatorType *ot = WM_operatortype_find(opname, 0);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
if (str && str[0] == '\0')
Various icon adjustments
2017-03-17 16:47:19 +03:00
return uiDefIconButO_ptr(block, type, ot, opcontext, icon, x, y, width, height, tip);
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
{
uiBlock *block;
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (block = lb->first; block; block = block->next)
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
if (block == lb->first || block->rect.ymin < min)
min = block->rect.ymin;
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
}
/* this call escapes if there's alignment flags */
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_order_flip(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
{
Use api function for flipping button list & rename to BLI_listbase_reverse
2014-06-25 19:33:35 +10:00
uiBut *but;
style cleanup: interface
2012-03-30 01:51:25 +00:00
float centy, miny = 10000, maxy = -10000;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (U.uiflag & USER_MENUFIXEDORDER)
Separate "content reordering" from "plain menus".
2009-06-16 02:40:39 +00:00
return;
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 (block->flag & UI_BLOCK_NO_FLIP)
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
return;
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
for (but = block->buttons.first; but; but = but->next) {
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
if (but->drawflag & UI_BUT_ALIGN) return;
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
if (but->rect.ymin < miny) miny = but->rect.ymin;
if (but->rect.ymax > maxy) maxy = but->rect.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
}
/* mirror trick */
style cleanup: interface
2012-03-30 01:51:25 +00:00
centy = (miny + maxy) / 2.0f;
for (but = block->buttons.first; but; but = but->next) {
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
but->rect.ymin = centy - (but->rect.ymin - centy);
but->rect.ymax = centy - (but->rect.ymax - centy);
SWAP(float, but->rect.ymin, but->rect.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
}
UI: cleanup next/prev order in menu code Recent flag re-order broke it since bits overlap, but logic here was far too complicated & fragile, Checked the type of each button when testing which direction to handle events as well as block direction. Now store the block-flipped state as a flag.
2014-11-15 14:32:23 +01:00
block->flag ^= UI_BLOCK_IS_FLIP;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
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_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 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_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
}
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
bool UI_but_flag_is_set(uiBut *but, int flag)
{
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;
}
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;
}
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_drag_set_id(uiBut *but, ID *id)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_ID;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if ((but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_SAFE_FREE(but->dragpoin);
but->dragflag &= ~UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragpoin = (void *)id;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
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_drag_set_rna(uiBut *but, PointerRNA *ptr)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_RNA;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if ((but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_SAFE_FREE(but->dragpoin);
but->dragflag &= ~UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragpoin = (void *)ptr;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
void UI_but_drag_set_path(uiBut *but, const char *path, const bool use_free)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_PATH;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if ((but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_SAFE_FREE(but->dragpoin);
but->dragflag &= ~UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragpoin = (void *)path;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if (use_free) {
but->dragflag |= UI_BUT_DRAGPOIN_FREE;
}
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
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_drag_set_name(uiBut *but, const char *name)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_NAME;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if ((but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_SAFE_FREE(but->dragpoin);
but->dragflag &= ~UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragpoin = (void *)name;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
/* value from button itself */
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_drag_set_value(uiBut *but)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_VALUE;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
void UI_but_drag_set_image(uiBut *but, const char *path, int icon, struct ImBuf *imb, float scale, const bool use_free)
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragtype = WM_DRAG_PATH;
Spelling fixes in comments and descriptions, patch by luzpaz. Differential Revision: https://developer.blender.org/D3732
2018-09-27 15:35:22 +02:00
ui_def_but_icon(but, icon, 0); /* no flag UI_HAS_ICON, so icon doesn't draw in button */
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if ((but->dragflag & UI_BUT_DRAGPOIN_FREE)) {
MEM_SAFE_FREE(but->dragpoin);
but->dragflag &= ~UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->dragpoin = (void *)path;
UI drag&drop: make code able to free dragpoin if needed. Only for image and strings for now. Needed for incomming filebrowser work.
2015-08-10 18:01:11 +02:00
if (use_free) {
but->dragflag |= UI_BUT_DRAGPOIN_FREE;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->imb = imb;
but->imb_scale = scale;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
}
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 *UI_but_operator_ptr_get(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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->opptr = MEM_callocN(sizeof(PointerRNA), "uiButOpPtr");
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 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 typed unsigned ints
2019-01-04 11:05:53 +11: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
{
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
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 */
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
if ((ownUnit != 0) || (but->rnaprop == NULL)) {
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
}
else {
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 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_butmenu_set(uiBlock *block, uiMenuHandleFunc 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
block->butm_func = func;
block->butm_func_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 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 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: 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
void UI_but_func_tooltip_set(uiBut *but, uiButToolTipFunc func, void *argN)
{
but->tip_func = func;
if (but->tip_argN) {
MEM_freeN(but->tip_argN);
}
but->tip_argN = argN;
}
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
void UI_but_func_pushed_state_set(uiBut *but, uiButPushedStateFunc func, void *arg)
{
but->pushed_state_func = func;
but->pushed_state_arg = arg;
}
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, const char *str, 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(block, UI_BTYPE_BLOCK, 0, str, x, y, width, height, arg, 0.0, 0.0, 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;
}
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, const char *str, 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(block, UI_BTYPE_BLOCK, 0, str, x, y, width, height, NULL, 0.0, 0.0, 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;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefPulldownBut(uiBlock *block, uiBlockCreateFunc func, void *arg, const char *str, 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(block, UI_BTYPE_PULLDOWN, 0, str, x, y, width, height, arg, 0.0, 0.0, 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);
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;
}
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, const char *str, 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(block, UI_BTYPE_PULLDOWN, 0, str, x, y, width, height, arg, 0.0, 0.0, 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;
}
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, const char *str, 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(block, UI_BTYPE_PULLDOWN, 0, str, x, y, width, height, arg, 0.0, 0.0, 0.0, 0.0, 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
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);
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
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);
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
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 *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(block, UI_BTYPE_PULLDOWN, 0, "", x, y, width, height, arg, 0.0, 0.0, 0.0, 0.0, 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
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;
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
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);
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;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 button containing both string label and icon */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefIconTextBlockBut(uiBlock *block, uiBlockCreateFunc func, void *arg, int icon, const char *str, 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(block, UI_BTYPE_BLOCK, 0, str, x, y, width, height, arg, 0.0, 0.0, 0.0, 0.0, tip);
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
/* XXX temp, old menu calls pass on icon arrow, which is now UI_BUT_ICON_SUBMENU flag */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (icon != ICON_RIGHTARROW_THIN) {
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, 0);
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;
2.5 Cleanup of conventions for icon placement in menus. Old code only allowed 1 icon per menu, forcing to pass on the sublevel menu icon with exception handling. Now sublevel icons are drawn automatically, allowing to add an icon before name too. (Check shift+a menu)
2009-04-30 17:27:30 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->flag |= UI_HAS_ICON;
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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->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);
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 but;
}
/* Block button containing icon */
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(block, UI_BTYPE_BLOCK, retval, "", x, y, width, height, arg, 0.0, 0.0, 0.0, 0.0, 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;
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
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);
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 but;
}
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefKeyevtButS(uiBlock *block, int retval, const char *str, int x, int y, short width, short height, short *spoin, 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(block, UI_BTYPE_KEY_EVENT | UI_BUT_POIN_SHORT, retval, str, x, y, width, height, spoin, 0.0, 0.0, 0.0, 0.0, tip);
ui_but_update(but);
Fix #19361: BGE keyboard sensor allowed to set mouse events too, should only be keyboard events.
2009-09-21 16:39:07 +00:00
return 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
}
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
/* short pointers hardcoded */
/* modkeypoin will be set to KM_SHIFT, KM_ALT, KM_CTRL, KM_OSKEY bits */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
uiBut *uiDefHotKeyevtButS(uiBlock *block, int retval, const char *str, int x, int y, short width, short height, short *keypoin, short *modkeypoin, const char *tip)
2.5 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +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(block, UI_BTYPE_HOTKEY_EVENT | UI_BUT_POIN_SHORT, retval, str, x, y, width, height, keypoin, 0.0, 0.0, 0.0, 0.0, tip);
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->modifier_key = *modkeypoin;
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 Keymap feature: RightMouse in pulldown menus allows to assign a new hotkey.
2009-07-28 16:48:02 +00:00
return 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
/* arg is pointer to string/name, use UI_but_func_search_set() below to make this work */
Changes to Brush texture workflow This changes how textures are accessed from Brushes, with the intention of simplifying the workflow, and reducing the amount of clicking. Rather than the previous texture slots (which didn't work as a stack anyway), brushes now have a single texture linked. Rather than taking time having to set up your slots in advance, you can now select and change textures directly as you sculpt/paint on the fly. For complex brushes, node textures can be used, or for fast access, it's easy to make a duplicate of your brush with the texture you like and assign a hotkey. Brush textures can now be chosen from a new Textures panel in the brush tool properties - click on the thumbnail to open a texture selector. This is done using a new variation on the ID template - the number of rows and columns to display in the popup can be customised in the UI scripts.
2010-01-03 08:37:18 +00:00
/* here a1 and a2, if set, control thumbnail preview rows/cols */
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, int maxlen, int x, int y, short width, short height, float a1, float a2, 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 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(block, UI_BTYPE_SEARCH_MENU, retval, "", x, y, width, height, arg, 0.0, maxlen, a1, a2, 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;
}
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
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
/**
Docs: arg names
2016-06-27 13:20:56 +10:00
* \param search_func, bfunc: both get it as \a arg.
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
* \param arg: user value,
* \param active: when set, button opens with this item visible and selected.
*/
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,
uiButSearchCreateFunc search_create_func,
uiButSearchFunc search_func, void *arg,
uiButHandleFunc bfunc, 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
{
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) */
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
if (search_create_func == NULL) {
search_create_func = ui_searchbox_create_generic;
}
but->search_create_func = search_create_func;
but->search_func = search_func;
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->search_arg = arg;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02: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
if (bfunc) {
#ifdef DEBUG
if (but->func) {
/* watch this, can be cause of much confusion, see: T47691 */
printf("%s: warning, overwriting button callback with search function callback!\n", __func__);
}
#endif
UI_but_func_set(but, bfunc, arg, active);
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02: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
/* search buttons show red-alert if item doesn't exist, not for menus */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (0 == (but->block->flag & UI_BLOCK_LOOP)) {
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 */
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->drawstr[0])
Revert "Add red alert in UI controls for datablock pointer properties" This reverts commit f5bc8ad4ce87165fc0648f1cd8c0ae1fb5f07281. We agreed there needs to be a better solution for this, see comments in rBf5bc8ad4ce87165.
2017-05-05 00:44:06 +02:00
ui_but_search_refresh(but);
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
}
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. */
static void operator_enum_search_cb(const struct bContext *C, void *but, const char *str, uiSearchItems *items)
{
wmOperatorType *ot = ((uiBut *)but)->optype;
PropertyRNA *prop = ot->prop;
if (prop == NULL) {
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 {
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 = UI_but_operator_ptr_get(but); /* Will create it if needed! */
Cleanup: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
const EnumPropertyItem *item, *item_array;
RNA API: use bool's for enum itemf callbacks.
2014-01-04 18:08:43 +11:00
bool do_free;
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
Fix i18n-related points in T47265 - mostly, fix non-translated items in enum-search popup menu.
2016-01-29 15:05:51 +01:00
RNA_property_enum_items_gettexted((bContext *)C, ptr, prop, &item_array, NULL, &do_free);
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
for (item = item_array; item->identifier; item++) {
Cleanup: comment line length (editors) Prevents clang-format wrapping text before comments.
2019-01-15 23:24:20 +11:00
/* note: need to give the index rather than the
* identifier because the enum can be freed */
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 (BLI_strcasestr(item->name, str)) {
Merge branch 'master' into blender2.8
2018-09-19 12:14:36 +10:00
if (false == UI_search_item_add(items, item->name, POINTER_FROM_INT(item->value), item->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
break;
}
}
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) {
MEM_freeN((void *)item_array);
}
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
}
}
static void operator_enum_call_cb(struct bContext *UNUSED(C), void *but, void *arg2)
{
wmOperatorType *ot = ((uiBut *)but)->optype;
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 *opptr = UI_but_operator_ptr_get(but); /* Will create it if needed! */
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.
* ui_apply_but_funcs_after() (in interface_handlers.c) called this func before checking operators,
* because one of its parameters is the button itself!
*/
}
else {
printf("%s: op->prop for '%s' is NULL\n", __func__, ot->idname);
}
}
}
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
/**
* Same parameters as for uiDefSearchBut, with additional operator type and properties, used by callback
* to call again the right op with the right options (properties values).
*/
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, int maxlen, int x, int y,
short width, short height, float a1, float a2, 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
{
uiBut *but;
but = uiDefSearchBut(block, arg, retval, icon, maxlen, x, y, width, height, a1, a2, 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(
Fix crash accessing nodes search menu Was caused by d49985c.
2016-03-02 17:57:16 +05:00
but, ui_searchbox_create_generic, operator_enum_search_cb,
UI: Add search-create callback Needed to support alternate search UI's, no functional changes.
2016-03-02 13:57:16 +11:00
but, operator_enum_call_cb, NULL);
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;
if (properties) {
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 = UI_but_operator_ptr_get(but);
More fix (cleanup) to r56063: remove call to RNA_create_pointer, it has already been called by uiButGetOperatorPtrRNA() if needed. (I thought it would also copy idproperties, but as it does not...).
2013-04-19 13:03:30 +00:00
/* Copy idproperties. */
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
}
return but;
}
UI: comments (doxygen tweaks)
2015-05-31 14:20:03 +10:00
/**
* push a new event onto event queue to activate the given button
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
* (usually a text-field) upon entering a popup
*/
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;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
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;
event.customdata = but;
UI: Use bool rather then int/short's where possible
2014-01-04 17:16:19 +11:00
event.customdatafree = 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;
}
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_string_info_get(bContext *C, uiBut *but, ...)
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
{
va_list args;
change uiButGetStrInfo() to use a trailing NULL arg rather then passing the number of args as an arg.
2012-12-02 04:51:15 +00:00
uiStringInfo *si;
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: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
const EnumPropertyItem *items = NULL, *item = NULL;
RNA API: use bool's for enum itemf callbacks.
2014-01-04 18:08:43 +11:00
int totitems;
bool free_items = false;
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
change uiButGetStrInfo() to use a trailing NULL arg rather then passing the number of args as an arg.
2012-12-02 04:51:15 +00:00
va_start(args, but);
while ((si = (uiStringInfo *) va_arg(args, void *))) {
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
int type = si->type;
char *tmp = NULL;
if (type == BUT_GET_LABEL) {
if (but->str) {
Fix for RMB Menu title including shortcut
2015-06-03 14:57:14 +10:00
const char *str_sep;
size_t str_len;
if ((but->flag & UI_BUT_HAS_SEP_CHAR) &&
(str_sep = strrchr(but->str, UI_SEP_CHAR)))
{
str_len = (str_sep - but->str);
}
else {
str_len = strlen(but->str);
}
tmp = BLI_strdupn(but->str, str_len);
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
}
Code cleanup: remove more string encoded menu functions
2014-02-15 11:35:40 +11:00
else {
style cleanup
2012-07-29 00:20:28 +00:00
type = BUT_GET_RNA_LABEL; /* Fail-safe solution... */
Code cleanup: remove more string encoded menu functions
2014-02-15 11:35:40 +11: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
}
else if (type == BUT_GET_TIP) {
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
if (but->tip_func) {
tmp = but->tip_func(C, but->tip_argN, but->tip);
}
else if (but->tip && but->tip[0])
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
tmp = BLI_strdup(but->tip);
else
style cleanup
2012-07-29 00:20:28 +00:00
type = BUT_GET_RNA_TIP; /* Fail-safe solution... */
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
}
fix for crash when displaying the tooltip for a non python menu (was introduced with recent translation/ui edits)
2012-07-26 16:55:34 +00: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
if (type == BUT_GET_RNAPROP_IDENTIFIER) {
if (but->rnaprop)
tmp = BLI_strdup(RNA_property_identifier(but->rnaprop));
}
else if (type == BUT_GET_RNASTRUCT_IDENTIFIER) {
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)
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
tmp = BLI_strdup(RNA_struct_identifier(but->rnapoin.type));
else if (but->optype)
tmp = BLI_strdup(but->optype->idname);
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_MENU, UI_BTYPE_PULLDOWN)) {
MenuType *mt = UI_but_menutype_get(but);
UI: show panel type in Python tooltips Handy when editing UI scripts.
2018-12-19 21:49:04 +11:00
if (mt) {
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
tmp = BLI_strdup(mt->idname);
UI: show panel type in Python tooltips Handy when editing UI scripts.
2018-12-19 21:49:04 +11:00
}
}
else if (but->type == UI_BTYPE_POPOVER) {
PanelType *pt = UI_but_paneltype_get(but);
if (pt) {
tmp = BLI_strdup(pt->idname);
}
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
}
}
else if (ELEM(type, BUT_GET_RNA_LABEL, BUT_GET_RNA_TIP)) {
if (but->rnaprop) {
if (type == BUT_GET_RNA_LABEL)
tmp = BLI_strdup(RNA_property_ui_name(but->rnaprop));
else {
const char *t = RNA_property_ui_description(but->rnaprop);
if (t && t[0])
tmp = BLI_strdup(t);
}
}
else if (but->optype) {
if (type == BUT_GET_RNA_LABEL)
tmp = BLI_strdup(RNA_struct_ui_name(but->optype->srna));
else {
const char *t = RNA_struct_ui_description(but->optype->srna);
if (t && t[0])
tmp = BLI_strdup(t);
}
}
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_MENU, UI_BTYPE_PULLDOWN)) {
MenuType *mt = UI_but_menutype_get(but);
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
if (mt) {
fix for crash when displaying the tooltip for a non python menu (was introduced with recent translation/ui edits)
2012-07-26 16:55:34 +00:00
/* not all menus are from python */
if (mt->ext.srna) {
if (type == BUT_GET_RNA_LABEL)
tmp = BLI_strdup(RNA_struct_ui_name(mt->ext.srna));
else {
const char *t = RNA_struct_ui_description(mt->ext.srna);
if (t && t[0])
tmp = BLI_strdup(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
}
}
}
}
else if (type == BUT_GET_RNA_LABEL_CONTEXT) {
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
const char *_tmp = BLT_I18NCONTEXT_DEFAULT;
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
if (but->rnaprop)
Fix for uiButGetStrInfo: We need a string value here, return BPY_I18NCONTEXT_DEFAULT_BPY when using default NULL label's context.
2013-02-24 08:46:01 +00:00
_tmp = RNA_property_translation_context(but->rnaprop);
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
else if (but->optype)
Fix for uiButGetStrInfo: We need a string value here, return BPY_I18NCONTEXT_DEFAULT_BPY when using default NULL label's context.
2013-02-24 08:46:01 +00:00
_tmp = RNA_struct_translation_context(but->optype->srna);
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_MENU, UI_BTYPE_PULLDOWN)) {
MenuType *mt = UI_but_menutype_get(but);
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
if (mt)
Fix for uiButGetStrInfo: We need a string value here, return BPY_I18NCONTEXT_DEFAULT_BPY when using default NULL label's context.
2013-02-24 08:46:01 +00:00
_tmp = RNA_struct_translation_context(mt->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
}
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
if (BLT_is_default_context(_tmp)) {
_tmp = BLT_I18NCONTEXT_DEFAULT_BPYRNA;
Fix for uiButGetStrInfo: We need a string value here, return BPY_I18NCONTEXT_DEFAULT_BPY when using default NULL label's context.
2013-02-24 08:46:01 +00:00
}
tmp = BLI_strdup(_tmp);
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
}
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
else if (ELEM(type, BUT_GET_RNAENUM_IDENTIFIER, BUT_GET_RNAENUM_LABEL, BUT_GET_RNAENUM_TIP)) {
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
PointerRNA *ptr = NULL;
PropertyRNA *prop = NULL;
int value = 0;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
/* get the enum property... */
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
if (but->rnaprop && RNA_property_type(but->rnaprop) == PROP_ENUM) {
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
/* enum property */
ptr = &but->rnapoin;
prop = but->rnaprop;
Fix Properties tabs all showing tooltip of active tab
2018-10-30 23:20:08 +01:00
value = (ELEM(but->type, UI_BTYPE_ROW, UI_BTYPE_TAB)) ? (int)but->hardmax : (int)ui_but_value_get(but);
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
}
else if (but->optype) {
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 *opptr = UI_but_operator_ptr_get(but);
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
wmOperatorType *ot = but->optype;
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Fix T55198: Preferences Keybindings Crash Operator sanitize function would be called for non operator props. Mistake from 88eafe078a5b5111c.
2018-05-25 14:01:25 +02:00
/* so the context is passed to itemf functions */
WM_operator_properties_sanitize(opptr, false);
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
/* if the default property of the operator is enum and it is set,
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
* fetch the tooltip of the selected value so that "Snap" and "Mirror"
* operator menus in the Anim Editors will show tooltips for the different
* operations instead of the meaningless generic operator 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);
}
}
}
Cleanup: strip trailing space from interface files
2018-05-23 10:47:12 +02:00
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
/* get strings from matching enum item */
if (ptr && prop) {
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
if (!item) {
int i;
Main Workspace Integration This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup) Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know! (Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.) == Main Changes/Features * Introduces the new Workspaces as data-blocks. * Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces. * Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces). * Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead. * Store screen-layouts (`bScreen`) per workspace. * Store an active screen-layout per workspace. Changing the workspace will enable this layout. * Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.) * Store an active render layer per workspace. * Moved mode switch from 3D View header to Info Editor header. * Store active scene in window (not directly workspace related, but overlaps quite a bit). * Removed 'Use Global Scene' User Preference option. * Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well. * Default .blend only contains one workspace ("General"). * Support appending workspaces. Opening files without UI and commandline rendering should work fine. Note that the UI is temporary! We plan to introduce a new global topbar that contains the workspace options and tabs for switching workspaces. == Technical Notes * Workspaces are data-blocks. * Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now. * A workspace can be active in multiple windows at the same time. * The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned). * The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that). * Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs. * `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those. * Added scene operators `SCENE_OT_`. Was previously done through screen operators. == BPY API Changes * Removed `Screen.scene`, added `Window.scene` * Removed `UserPreferencesView.use_global_scene` * Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces` * Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer` * Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name) == What's left? * There are a few open design questions (T50521). We should find the needed answers and implement them. * Allow adding and removing individual workspaces from workspace configuration (needs UI design). * Get the override system ready and support overrides per workspace. * Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc). * Allow enabling add-ons per workspace. * Support custom workspace keymaps. * Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later. * Get the topbar done. * Workspaces need a proper icon, current one is just a placeholder :) Reviewed By: campbellbarton, mont29 Tags: #user_interface, #bf_blender_2.8 Maniphest Tasks: T50521 Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
Display enum descriptions in tooltips for operators using a "type" or "mode" property Changes: This commit adds a second line to the tooltips (below the generic operator description) showing the appropriate description for each enum option. This brings it more into line enum properties in Blender which also show this sort of information. Rationale: Operators such as Snap and Mirror in the Action and Graph Editors use an enum to control their behaviour (respectively, "how to snap" or "what to use as the mirror line"). In the menus, these options are displayed using a submenu, but hovering over each of these items for more information from a tooltip only shows the (relatively unhelpful) generic operator tooltip/description. Another area where these descriptions are useful is for Keying Sets, where it's now possible to see the descriptions for what each Keying Set does/affects/requires. Again, this is more helpful than just the generic tooltip, which would be something like "Insert keyframes using a Keying Set".
2012-10-08 05:57:52 +00:00
RNA_property_enum_items_gettexted(C, ptr, prop, &items, &totitems, &free_items);
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
for (i = 0, item = items; i < totitems; i++, item++) {
if (item->identifier[0] && item->value == value)
break;
}
}
Fix crash on creating tooltip for sequencer's gl preview mode Issue was caused by missed value for this enum, fixed by adding check in tooltip generation. Default value for this enum should also be fixed, but that would be in separated commit.
2012-07-12 07:15:32 +00:00
if (item && item->identifier) {
if (type == BUT_GET_RNAENUM_IDENTIFIER)
tmp = BLI_strdup(item->identifier);
else if (type == BUT_GET_RNAENUM_LABEL)
tmp = BLI_strdup(item->name);
else if (item->description && item->description[0])
tmp = BLI_strdup(item->description);
}
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
}
}
else if (type == BUT_GET_OP_KEYMAP) {
tweak to recent commit, don't show keymap in menu tooltips.
2013-06-02 15:58:43 +00:00
if (!ui_block_is_menu(but->block)) {
char buf[128];
if (ui_but_event_operator_string(C, but, buf, sizeof(buf))) {
tmp = BLI_strdup(buf);
}
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
}
}
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
else if (type == BUT_GET_PROP_KEYMAP) {
/* for properties that are bound to one of the context cycle, etc. keys... */
char buf[128];
if (ui_but_event_property_operator_string(C, but, buf, sizeof(buf))) {
tmp = BLI_strdup(buf);
}
}
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
si->strinfo = tmp;
}
fix for misc errors - reference to out of scope stack var - freeing fixes size array (never allocated) - add matching va_end for va_start
2013-07-13 05:46:48 +00:00
va_end(args);
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: Use const for RNA EnumPropertyItem args Practically all access to enum data is read-only.
2017-10-18 15:07:26 +11:00
if (free_items && items) {
MEM_freeN((void *)items);
}
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
void UI_init(void)
{
ui_resources_init();
}
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
/* after reading userdef file */
Cleanup: getting rid of G.main. Sometimes one needs a *lot* of changes for a single G.main... :/
2018-06-08 12:16:37 +02:00
void UI_init_userdef(Main *bmain)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
/* fix saved themes */
Cleanup: getting rid of G.main. Sometimes one needs a *lot* of changes for a single G.main... :/
2018-06-08 12:16:37 +02:00
init_userdef_do_versions(bmain);
2.5 Summary of ain features: - Themes and Styles are now editable. - CTRL+U "Save user defaults" now goes to new .B25.blend, so you can use 2.4x and 2.5x next to each other. If B25 doesn't exist, it reads the regular .B.blend - Press Tkey in 3d window for (unfinished) toolbar WIP. It now only shows the last operator, if appropriate. Nkey properties moved to the other side. A lot of work was done on removing old themes for good and properly getting it work with the 2.5 region system. Here's some notes; - Buttons now all have a complete set of colors, based on button classifications (See outliner -> user prefs -> Interface - Theme colors have been extended with basic colors for region types. Currently colors are defined for Window, Header, List/Channels and for Button/Tool views. The screen manager handles this btw, so a TH_BACK will always pick the right backdrop color. - Menu backdrops are in in Button theme colors. Floating Panels will be in the per-space type Themes. - Styles were added in RNA too, but only for the font settings now. Only Panel font, widget font and widget-label work now. The 'group label' will be for templates mostly. Style settings will be expanded with spacing defaults, label conventions, etc. - Label text colors are stored in per-space Theme too, to make sure they fit. Same goes for Panel title color. Note that 'shadow' for fonts can conflict with text colors; shadow color is currently stored in Style... shadow code needs a bit of work still.
2009-04-27 13:44:11 +00:00
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
}
minor cleanup - use NULL rather then 0 for pointers - use static functions where possible - add own includes to ensure func's and their declarations don't get out of sync.
2011-11-14 16:05:44 +00:00
void UI_reinit_font(void)
Translation: reload font on enabling/disabling use international fonts.
2011-09-21 15:15:30 +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
void UI_exit(void)
{
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
}
Copy Permalink