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
a3df65dea819309496447a26ddf4d7dbe0c3203a
blender-archive/source/blender/editors/interface/interface_regions.c

3152 lines
89 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
/*
2.5 More notifier cleanup; - removed view2d sync notifier, its data operations are too complex for UI hints/notes, direct calls work too :) - updated missing gpl header in region file Noticed weird delay on menu refreshing now... will check.
2008-12-16 13:19:02 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
*
* 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.
2.5 More notifier cleanup; - removed view2d sync notifier, its data operations are too complex for UI hints/notes, direct calls work too :) - updated missing gpl header in region file Noticed weird delay on menu refreshing now... will check.
2008-12-16 13:19:02 +00:00
*
* The Original Code is Copyright (C) 2008 Blender Foundation.
* All rights reserved.
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
doxygen: blender/editors tagged.
2011-02-27 20:29:51 +00:00
/** \file blender/editors/interface/interface_regions.c
* \ingroup edinterface
*/
UI: getting popup menus to work again, just the internal interface and event handling code still, how it integrates with operators and handlers is not worked out yet. For testing, Ctrl+Q quit now shows a confirmation popup using the following call: okee_operator(C, "WM_OT_exit_blender", "Quit Blender");
2008-12-15 19:19:39 +00:00
#include <stdarg.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 <stdlib.h>
#include <string.h>
bugfix [#24179] Button "Loop Cut and Slide" on Mesh Tools not work also added a message in the tooltip to say `why` a buttons disabled. depends on the operators poll setting the message.
2010-10-08 11:33:10 +00:00
#include <assert.h>
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
#include "MEM_guardedalloc.h"
2.5 Grand cleanup: - removal of FTF and ftfont dir - removal of text.c which wrapped it - wrapped old text drawing code temporarily, need to decide how 'style' will behave per editor when you draw strings outside interface code.... wouldn't be very useful to set fonts locally all over?
2009-04-10 16:30:28 +00:00
#include "DNA_userdef_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"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 "BLI_blenlib.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"
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
#include "BLI_ghash.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
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
#include "PIL_time.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"
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 "BKE_screen.h"
UI: report if WM_OT_call_menu uses an unknown menu
2014-02-10 14:17:33 +11:00
#include "BKE_report.h"
fix [#30087] operator_context is different for popup and submenu's *TODO, after 2.62* having context different for menu vs submenu is quite confusing, now they are both: WM_OP_INVOKE_REGION_WIN this changes WM_menu_invoke behavior.
2012-10-26 06:22:54 +00:00
#include "BKE_global.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"
2.5: WM Compositing * Triple Buffer is now more complete: - Proper handling of window resize, duplicate, etc. - It now uses 3x3 textures (or less) if the power of two sizes do not match well. That still has a worst case wast of 23.4%, but better than 300%. - It can also use the ARB/NV/EXT_texture_rectangle extension now, which may be supported on hardware that does not support ARB_texture_non_power_of_two. - Gesture, menu and brushe redraws now require no redraws at all from the area regions. So even on a high poly scene just moving the paint cursor or opening a menu should be fast. * Testing can be done by setting the "Window Draw Method" in the User Preferences in the outliner. "Overlap" is still default, since "Triple Buffer" has not been tested on computers other than mine, would like to avoid crashing Blender on startup in case there is a common bug, but it's ready for testing now. - For reference "Full" draws the full window each time. - "Triple Buffer" should work for both swap copy and swap exchange systems, the latter still need the -E command line option for "Overlap". - Resizing and going fullscreen still gives flicker here but no more than "Full" drawing. * Partial Redraw was added. ED_region_tag_redraw_partial takes a rect in window coordinates to define a subarea of the region. On region draw it will then set glScissor to a smaller area, and ar->drawrct will always be set to either the partial or full window rect. The latter can then be used for clipping in the 3D view or clipping interface drawing. Neither is implemented yet.
2009-01-23 03:52:52 +00:00
#include "wm_draw.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_subwindow.h"
2.5 Simple toolbox-style menu system. Brecht will review it though, and/or check on way to use it for menus. I tried to avoid uiBlock and rna stuff all over. :) Quick image test: http://www.blender.org/bf/rt.jpg Examples you can read in: - editors/screen/screen_ops.c:testing123() (press F5) - editors/object/object_edit.c:object_add_primitive_invoke() (press SHIFT+A) Concept is simple: uiMenuBegin(): returns a handle. uiMenuEnd(): puts it all to work. In between you can add items like: uiMenuItemVal(): a name, icon, retval (use uiMenuFunc()) uiMenuItemO(): an operator + icon uiMenuItemEnumO(): an operator, property name, value Sublevels go easy too: uiMenuLevel(): creates item for sublevel, with function pointer. Inside that function you can use all menu calls again. Levels can go as deep you want. uiMenuLevelEnumO(): creates operator sublevel for an enum
2009-01-25 20:22:05 +00:00
#include "RNA_access.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 "BIF_gl.h"
#include "UI_interface.h"
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
#include "UI_interface_icons.h"
2.5 - Tooltips now respect view2d view (rna viewer). - Bugfix in viewd.c UI_view2d_view_to_region() (typo)
2008-12-03 17:11:50 +00:00
#include "UI_view2d.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 Grand cleanup: - removal of FTF and ftfont dir - removal of text.c which wrapped it - wrapped old text drawing code temporarily, need to decide how 'style' will behave per editor when you draw strings outside interface code.... wouldn't be very useful to set fonts locally all over?
2009-04-10 16:30:28 +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 Grand cleanup: - removal of FTF and ftfont dir - removal of text.c which wrapped it - wrapped old text drawing code temporarily, need to decide how 'style' will behave per editor when you draw strings outside interface code.... wouldn't be very useful to set fonts locally all over?
2009-04-10 16:30:28 +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 "ED_screen.h"
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"
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: tweak menu padding and make separator line more visible. Adds some padding to the left of the icon, adds more space around the separator line and make it more visible, and add some spacing at the top and bottom of the menu. Ref T37794 Reviewed By: dingto, billrey Differential Revision: https://developer.blender.org/D223
2014-01-17 00:23:00 +01:00
#define MENU_PADDING (int)(0.2f * UI_UNIT_Y)
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
#define MENU_BORDER (int)(0.3f * U.widget_unit)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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 int rna_property_enum_step(const bContext *C, PointerRNA *ptr, PropertyRNA *prop, int direction)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: refactor 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
EnumPropertyItem *item_array;
int totitem;
bool free;
int value;
int i, i_init;
int step = (direction < 0) ? -1 : 1;
int step_tot = 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 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((bContext *)C, ptr, prop, &item_array, &totitem, &free);
value = RNA_property_enum_get(ptr, prop);
i = RNA_enum_from_value(item_array, value);
i_init = i;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 menus to remove menus encoded in strings On every redraw a single unopened dropdown boxe would translate and convert every EnumPropertyItem into a string, then decode every item, and search those items to find the name of the button to draw. Replace this with a custom menu callback for RNA enums, tooltips for enums now show too.
2014-02-10 12:52:35 +11:00
do {
i = mod_i(i + step, totitem);
if (item_array[i].identifier[0]) {
step_tot += step;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
} while ((i != i_init) && (step_tot != direction));
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: refactor 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 (i != i_init) {
value = item_array[i].value;
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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) {
MEM_freeN(item_array);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
return 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
}
Fix T45944: Ctrl+Wheel to cycle values failes in toolshelf Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes) This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
2015-09-05 19:28:24 +02:00
bool ui_but_menu_step_poll(const uiBut *but)
2.5 Several usablity tweaks: - Search menu allows ScrollWheel to view items - Tooltip on button on bottom of window showed wrong - Tooltips were popping up while draggin (MMB) or scrolling (wheel). Now they stay away. - Stolen from Gimp (blame venomgfx for hint!): ScrollWheel allows to go over menu items and use number buttons, only on mouse-over. Note for devs: the WM_event_add_mousemove() call (to add a fake event to bring UI back alive after view changes) now works much more reliably. It ensures the mouse move is only handled after all notifiers/redraws were done.
2009-06-06 13:35:04 +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
BLI_assert(but->type == UI_BTYPE_MENU);
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
/* currenly only RNA buttons */
UI: support cycling callback for non RNA menus
2015-11-16 06:26:25 +11:00
return ((but->menu_step_func != NULL) ||
(but->rnaprop && RNA_property_type(but->rnaprop) == PROP_ENUM));
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
}
int ui_but_menu_step(uiBut *but, int direction)
{
if (ui_but_menu_step_poll(but)) {
UI: support cycling callback for non RNA menus
2015-11-16 06:26:25 +11:00
if (but->menu_step_func) {
return but->menu_step_func(but->block->evil_C, direction, but->poin);
}
else {
return rna_property_enum_step(but->block->evil_C, &but->rnapoin, but->rnaprop, direction);
}
2.5 Several usablity tweaks: - Search menu allows ScrollWheel to view items - Tooltip on button on bottom of window showed wrong - Tooltips were popping up while draggin (MMB) or scrolling (wheel). Now they stay away. - Stolen from Gimp (blame venomgfx for hint!): ScrollWheel allows to go over menu items and use number buttons, only on mouse-over. Note for devs: the WM_event_add_mousemove() call (to add a fake event to bring UI back alive after view changes) now works much more reliably. It ensures the mouse move is only handled after all notifiers/redraws were done.
2009-06-06 13:35:04 +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
printf("%s: cannot cycle button '%s'\n", __func__, but->str);
return 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
}
2.5 Several usablity tweaks: - Search menu allows ScrollWheel to view items - Tooltip on button on bottom of window showed wrong - Tooltips were popping up while draggin (MMB) or scrolling (wheel). Now they stay away. - Stolen from Gimp (blame venomgfx for hint!): ScrollWheel allows to go over menu items and use number buttons, only on mouse-over. Note for devs: the WM_event_add_mousemove() call (to add a fake event to bring UI back alive after view changes) now works much more reliably. It ensures the mouse move is only handled after all notifiers/redraws were done.
2009-06-06 13:35:04 +00:00
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/******************** Creating Temporary regions ******************/
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 ARegion *ui_region_temp_add(bScreen *sc)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
ARegion *ar;
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = MEM_callocN(sizeof(ARegion), "area 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
BLI_addtail(&sc->regionbase, ar);
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->regiontype = RGN_TYPE_TEMPORARY;
ar->alignment = RGN_ALIGN_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
return ar;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_region_temp_remove(bContext *C, bScreen *sc, 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
{
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
wmWindow *win = CTX_wm_window(C);
if (win)
wm_draw_region_clear(win, ar);
2.5: UV Editor module porting pretty much finished now, only missing still is mirror transform. This commits adds the remaining operators: * UV mapping operators (U key menu): cube, sphere, cylinder, etc. * Hide/Show operators. And solves most XXX's, including: * Fix bad includes and calls into space image. * Aspect ratio correction. * Create UVs if they don't exist yet on unwrap. * Assign image to UVs. * Drawing proportional edit circle.
2009-02-09 20:58:31 +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
ED_region_exit(C, ar);
style cleanup: interface
2012-03-30 01:51:25 +00:00
BKE_area_region_free(NULL, ar); /* NULL: no spacetype */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_freelinkN(&sc->regionbase, ar);
}
/************************* Creating Tooltips **********************/
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
#define UI_TIP_PAD_FAC 1.3f
#define UI_TIP_PADDING (int)(UI_TIP_PAD_FAC * UI_UNIT_Y)
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
#define UI_TIP_MAXWIDTH 600
2.5: UI * Fix issue where it would automatically scroll when collapsing panels. * Fix panel dragging not taking zoom level into account. * Fix enum menu having too small default width in headers. * Fix tooltips not showing shortcuts etc. if there was not tooltip defined for the button. * Fix some refresh issues with color ramps. * Add a bit more space between columns in the layout engine. * Make scrollers darker so they are less distracting, and highlight instead of reverse shading when dragging.
2009-07-23 20:50:24 +00:00
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
#define MAX_TOOLTIP_LINES 8
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
typedef struct uiTooltipData {
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
rcti bbox;
uiFontStyle fstyle;
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
char lines[MAX_TOOLTIP_LINES][2048];
char header[2048], active_info[2048];
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
struct {
enum {
UI_TIP_STYLE_NORMAL = 0,
UI_TIP_STYLE_HEADER,
UI_TIP_STYLE_MONO,
Correct enum size incase compiler makes enum signed
2014-07-01 18:36:28 +10:00
} style : 3;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
enum {
UI_TIP_LC_MAIN = 0, /* primary text */
UI_TIP_LC_VALUE, /* the value of buttons (also shortcuts) */
UI_TIP_LC_ACTIVE, /* titles of active enum values */
UI_TIP_LC_NORMAL, /* regular text */
UI_TIP_LC_PYTHON, /* Python snippet */
UI_TIP_LC_ALERT, /* description of why operator can't run */
} color_id : 4;
int is_pad : 1;
} format[MAX_TOOLTIP_LINES];
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
struct {
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
unsigned int x_pos; /* x cursor position at the end of the last line */
unsigned int lines; /* number of lines, 1 or more with word-wrap */
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
} line_geom[MAX_TOOLTIP_LINES];
int wrap_width;
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
int totline;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
int toth, lineh;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
} uiTooltipData;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
#define UI_TIP_LC_MAX 6
BLI_STATIC_ASSERT(UI_TIP_LC_MAX == UI_TIP_LC_ALERT + 1, "invalid lc-max");
BLI_STATIC_ASSERT(sizeof(((uiTooltipData *)NULL)->format[0]) <= sizeof(int), "oversize");
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
static void rgb_tint(
float col[3],
float h, float h_strength,
float v, float v_strength)
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
{
float col_hsv_from[3];
float col_hsv_to[3];
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
rgb_to_hsv_v(col, col_hsv_from);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
col_hsv_to[0] = h;
col_hsv_to[1] = h_strength;
col_hsv_to[2] = (col_hsv_from[2] * (1.0f - v_strength)) + (v * v_strength);
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
hsv_to_rgb_v(col_hsv_to, col);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
static void ui_tooltip_region_draw_cb(const bContext *UNUSED(C), 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
{
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
const float pad_px = UI_TIP_PADDING;
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiTooltipData *data = ar->regiondata;
uiWidgetColors *theme = ui_tooltip_get_theme();
rcti bbox = data->bbox;
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
float tip_colors[UI_TIP_LC_MAX][3];
float *main_color = tip_colors[UI_TIP_LC_MAIN]; /* the color from the theme */
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
float *value_color = tip_colors[UI_TIP_LC_VALUE];
float *active_color = tip_colors[UI_TIP_LC_ACTIVE];
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
float *normal_color = tip_colors[UI_TIP_LC_NORMAL];
float *python_color = tip_colors[UI_TIP_LC_PYTHON];
float *alert_color = tip_colors[UI_TIP_LC_ALERT];
float background_color[3];
float tone_bg;
Fix #35342: multisample antialiasing makes tooltips look blurry.
2013-05-13 13:45:45 +00:00
int i, multisample_enabled;
/* disable AA, makes widgets too blurry */
OpenGL: clean up use of old extensions
2015-11-24 02:20:38 -05:00
multisample_enabled = glIsEnabled(GL_MULTISAMPLE);
Fix #35342: multisample antialiasing makes tooltips look blurry.
2013-05-13 13:45:45 +00:00
if (multisample_enabled)
OpenGL: clean up use of old extensions
2015-11-24 02:20:38 -05:00
glDisable(GL_MULTISAMPLE);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
Partial fix for T41749 Tool-tips and header-text used a different pixel alignment from the rest of the UI. This causes blurry text with multi-sample with NVidia. Other text still needs the issue resolved (View3d info for eg)
2014-09-10 13:34:17 +10:00
wmOrtho2_region_ui(ar);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
/* draw background */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_draw_tooltip_background(UI_style_get(), NULL, &bbox);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
/* set background_color */
rgb_uchar_to_float(background_color, (const unsigned char *)theme->inner);
/* calculate normal_color */
rgb_uchar_to_float(main_color, (const unsigned char *)theme->text);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
copy_v3_v3(active_color, main_color);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
copy_v3_v3(normal_color, main_color);
copy_v3_v3(python_color, main_color);
copy_v3_v3(alert_color, main_color);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
copy_v3_v3(value_color, main_color);
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
/* find the brightness difference between background and text colors */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Revert part of recent color-management commit This adds back rgb_to_grayscale, not all color is managed or depends on the current loaded blend file's CM options. Noted in comments that this is only to be used outside the CM pipeline.
2015-03-19 14:09:01 +11:00
tone_bg = rgb_to_grayscale(background_color);
/* tone_fg = rgb_to_grayscale(main_color); */
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* mix the colors */
Cleanup: spelling grey -> gray
2015-03-19 14:14:48 +11:00
rgb_tint(value_color, 0.0f, 0.0f, tone_bg, 0.2f); /* light gray */
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
rgb_tint(active_color, 0.6f, 0.2f, tone_bg, 0.2f); /* light blue */
Cleanup: spelling grey -> gray
2015-03-19 14:14:48 +11:00
rgb_tint(normal_color, 0.0f, 0.0f, tone_bg, 0.4f); /* gray */
rgb_tint(python_color, 0.0f, 0.0f, tone_bg, 0.5f); /* dark gray */
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
rgb_tint(alert_color, 0.0f, 0.8f, tone_bg, 0.1f); /* red */
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +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
/* draw text */
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
BLF_wordwrap(data->fstyle.uifont_id, data->wrap_width);
BLF_wordwrap(blf_mono_font, data->wrap_width);
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
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
bbox.xmin += 0.5f * pad_px; /* add padding to the text */
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
bbox.ymax -= 0.25f * pad_px;
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
patch [#30620] Wiki Quick Hack: Make Tooltip Text Colour Themeable from luke frisken (lfrisken), with some edits. some tooltip colors weren't visible with different backgrounds, now the base tooltip color is used and tinted for python/alert/shortcuts etc. the tint colors are still hard coded.
2012-03-22 20:24:11 +00:00
for (i = 0; i < data->totline; i++) {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
bbox.ymin = bbox.ymax - (data->lineh * data->line_geom[i].lines);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
if (data->format[i].style == UI_TIP_STYLE_HEADER) {
/* draw header and active data (is done here to be able to change color) */
uiFontStyle fstyle_header = data->fstyle;
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
float xofs, yofs;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* override text-style */
fstyle_header.shadow = 1;
Revert part of recent color-management commit This adds back rgb_to_grayscale, not all color is managed or depends on the current loaded blend file's CM options. Noted in comments that this is only to be used outside the CM pipeline.
2015-03-19 14:09:01 +11:00
fstyle_header.shadowcolor = rgb_to_grayscale(tip_colors[UI_TIP_LC_MAIN]);
UI: tooltips, blurry and incorrect rhs-padding in recent update D634 by Severin
2014-07-07 10:43:32 +10:00
fstyle_header.shadx = fstyle_header.shady = 0;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
fstyle_header.shadowalpha = 1.0f;
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
fstyle_header.word_wrap = true;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10: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_fontstyle_set(&fstyle_header);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
glColor3fv(tip_colors[UI_TIP_LC_MAIN]);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_draw(&fstyle_header, &bbox, data->header);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
/* offset to the end of the last line */
xofs = data->line_geom[i].x_pos;
yofs = data->lineh * (data->line_geom[i].lines - 1);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
bbox.xmin += xofs;
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
bbox.ymax -= yofs;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
glColor3fv(tip_colors[UI_TIP_LC_ACTIVE]);
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
fstyle_header.shadow = 0;
UI_fontstyle_draw(&fstyle_header, &bbox, data->active_info);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
/* undo offset */
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
bbox.xmin -= xofs;
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
bbox.ymax += yofs;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
else if (data->format[i].style == UI_TIP_STYLE_MONO) {
uiFontStyle fstyle_mono = data->fstyle;
fstyle_mono.uifont_id = blf_mono_font;
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
fstyle_mono.word_wrap = true;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10: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_fontstyle_set(&fstyle_mono);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* XXX, needed because we dont have mono in 'U.uifonts' */
BLF_size(fstyle_mono.uifont_id, fstyle_mono.points * U.pixelsize, U.dpi);
glColor3fv(tip_colors[data->format[i].color_id]);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_draw(&fstyle_mono, &bbox, data->lines[i]);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
else {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
uiFontStyle fstyle_normal = data->fstyle;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
BLI_assert(data->format[i].style == UI_TIP_STYLE_NORMAL);
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
fstyle_normal.word_wrap = true;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* draw remaining data */
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
UI_fontstyle_set(&fstyle_normal);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
glColor3fv(tip_colors[data->format[i].color_id]);
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
UI_fontstyle_draw(&fstyle_normal, &bbox, data->lines[i]);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
bbox.ymax -= data->lineh * data->line_geom[i].lines;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
if ((i + 1 != data->totline) && data->format[i + 1].is_pad) {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
bbox.ymax -= data->lineh * (UI_TIP_PAD_FAC - 1);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
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
}
Fix #35342: multisample antialiasing makes tooltips look blurry.
2013-05-13 13:45:45 +00:00
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
BLF_disable(data->fstyle.uifont_id, BLF_WORD_WRAP);
BLF_disable(blf_mono_font, BLF_WORD_WRAP);
Fix #35342: multisample antialiasing makes tooltips look blurry.
2013-05-13 13:45:45 +00:00
if (multisample_enabled)
OpenGL: clean up use of old extensions
2015-11-24 02:20:38 -05:00
glEnable(GL_MULTISAMPLE);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
static void ui_tooltip_region_free_cb(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
{
uiTooltipData *data;
style cleanup: interface
2012-03-30 01:51:25 +00:00
data = ar->regiondata;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data);
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->regiondata = 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
}
ARegion *ui_tooltip_create(bContext *C, ARegion *butregion, uiBut *but)
{
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
const float pad_px = UI_TIP_PADDING;
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
wmWindow *win = CTX_wm_window(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
uiStyle *style = UI_style_get();
2.5 Part one of wrapping up area/region management. Read design doc here: http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AreaManager This commit: - brings keymap storage to WM, based on names/types. This structure allows rna-ifying it too, so you can browse keymaps etc. - creating areas and regions works slightly different now, wich regiontypes stored in areatype. Todo: - better callbacks and structure for defining which handlers need to be added. - using region types to validate regions - proper implementation of local region data - code method for customizing keymaps. Current idea is that you have to indicate an entire keymap to be custom, to prevent too complicated merging problems of default and custom maps (like order, multiple keys for same operator, disabling options, etc).
2008-12-08 15:02:57 +00:00
static ARegionType type;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
ARegion *ar;
uiTooltipData *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
/* IDProperty *prop;*/
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
char buf[512];
UI: Resolve T37917, disable tooltip scaling (zoomout only)
2013-12-23 12:46:50 +11:00
/* aspect values that shrink text are likely unreadable */
const float aspect = min_ff(1.0f, but->block->aspect);
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
int fonth, fontw;
int winx, ofsx, ofsy, h, i;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rctf rect_fl;
rcti rect_i;
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
int font_flag = 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 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
uiStringInfo but_tip = {BUT_GET_TIP, NULL};
uiStringInfo enum_label = {BUT_GET_RNAENUM_LABEL, NULL};
uiStringInfo enum_tip = {BUT_GET_RNAENUM_TIP, NULL};
uiStringInfo op_keymap = {BUT_GET_OP_KEYMAP, NULL};
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
uiStringInfo prop_keymap = {BUT_GET_PROP_KEYMAP, NULL};
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
uiStringInfo rna_struct = {BUT_GET_RNASTRUCT_IDENTIFIER, NULL};
uiStringInfo rna_prop = {BUT_GET_RNAPROP_IDENTIFIER, NULL};
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_NO_TOOLTIP)
UI: List Template tweaks to get it a bit more usable * Mouse wheel now scrolls the list. * Up/down key and alt mouse wheel change the active item. * Adding/removing items from the list now automatically scrolls so the active item is in the view. * Shift mouse wheel changes the size of the list widget to display more items. Lazy replacement for a proper grip. * Shape key list now displays the influence value next to the name, * Also fix the range of the value slider to match the defined min/max range.
2009-10-21 20:58:10 +00:00
return 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
/* create tooltip data */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data = MEM_callocN(sizeof(uiTooltipData), "uiTooltipData");
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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_info_get(C, but, &but_tip, &enum_label, &enum_tip, &op_keymap, &prop_keymap, &rna_struct, &rna_prop, NULL);
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
/* Tip */
if (but_tip.strinfo) {
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
BLI_strncpy(data->header, but_tip.strinfo, sizeof(data->lines[0]));
if (enum_label.strinfo) {
BLI_snprintf(data->header, sizeof(data->header), "%s: ", but_tip.strinfo);
BLI_strncpy(data->active_info, enum_label.strinfo, sizeof(data->lines[0]));
Fix for [#35224] Transform Orientation - order inconsistency Fix turned out to remove as much "manual UI" from 3D view header as possible. Mode selector and all transform manipulators/orientations stuff are now RNA-based UI (leaving basically only edit mesh select modes with custom handlers, as they have some quite specific features). To achieve this, four main modifications were done: * enum-operator-generated menus are now MENU (i.e. dropdown lists) in headers too. * All bit-flag enums expanded in ROW buttons now have a handling consistent with e.g. layers, or what we already have for transform manipulators, i.e. clicking select only one element, shift-click to select multiple ones. * Consequently, the three RNA booleans manipulators flags are merged into a single bit-flag enum (yes, this is also an API change, though I doubt many scripts use it). * Now the width of enum-based dropdown lists is computed from longest item name in enum, no more from a dummy place holder string (when no label/name is given). All this allows to remove some code from 3DView/transform areas, that was actually mostly duplicating RNA/operator one. Also done a few optimizations here and there (among others, do not pass &numitems to RNA_property_enum_items() when you do not need it, saves at least an iteration over enum items to count them). Many thanks to Brecht for the reviews!
2013-05-12 13:16:11 +00:00
}
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].style = UI_TIP_STYLE_HEADER;
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
data->totline++;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* special case enum rna 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
if ((but->type & UI_BTYPE_ROW) && but->rnaprop && RNA_property_flag(but->rnaprop) & PROP_ENUM_FLAG) {
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
BLI_strncpy(data->lines[data->totline], IFACE_("(Shift-Click/Drag to select multiple)"),
sizeof(data->lines[0]));
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].color_id = UI_TIP_LC_NORMAL;
data->totline++;
}
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
}
/* Enum item label & tip */
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
if (enum_tip.strinfo) {
BLI_strncpy(data->lines[data->totline], enum_tip.strinfo, sizeof(data->lines[0]));
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_VALUE;
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
data->totline++;
}
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
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
/* Op shortcut */
if (op_keymap.strinfo) {
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Shortcut: %s"), op_keymap.strinfo);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_VALUE;
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
data->totline++;
}
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
/* Property context-toggle shortcut */
if (prop_keymap.strinfo) {
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Shortcut: %s"), prop_keymap.strinfo);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_VALUE;
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->totline++;
}
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
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)) {
Fix T38640: password values showed in tooltips also disable copying password text.
2014-02-15 12:05:51 +11:00
/* better not show the value of a password */
if ((but->rnaprop && (RNA_property_subtype(but->rnaprop) == PROP_PASSWORD)) == 0) {
/* full string */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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, buf, sizeof(buf));
Fix T38640: password values showed in tooltips also disable copying password text.
2014-02-15 12:05:51 +11:00
if (buf[0]) {
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Value: %s"), buf);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_VALUE;
Fix T38640: password values showed in tooltips also disable copying password text.
2014-02-15 12:05:51 +11:00
data->totline++;
}
2.5: Render * UI layout for scene buttons has quite some changes, I tried to better organize things according to the pipeline, and also showing important properties by default, and collapsing less important ones. Some changes compared to 2.4x: * Panorama is now a Camera property. * Sequence and Compositing are now enabled by default, but will only do something when there is a node tree using nodes, or a strip in the sequence editor. * Enabling Full Sample now automatically enables Save Buffers too. * Stamp option to include info in file is removed, it now simply always does this if one of the stamp infos is enabled. * Xvid, H.264 and Ogg Theora are now directly in the file format menu, but still using FFMPEG. Unfortunately Ogg is broken at the moment (also in 2.4x), so that's disabled. And Xvid crashes on 64bit linux, maybe solvable by upgrading extern/xvidcore/, using ubuntu libs makes it work. * Organized file format menu by image/movie types. Added: * Render layers RNA wrapped, operatorized, layouted. * FFMPEG format/codec options are now working. Defaults changed: * Compositing & Sequencer enabled. * Tiles set to 8x8. * Time/Date/Frame/Scene/Camera/Filename enabled for stamp.
2009-07-13 19:09:13 +00:00
}
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: 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) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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);
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
if (unit_type == PROP_UNIT_ROTATION) {
if (RNA_property_type(but->rnaprop) == PROP_FLOAT) {
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
float value = RNA_property_array_check(but->rnaprop) ?
RNA_property_float_get_index(&but->rnapoin, but->rnaprop, but->rnaindex) :
RNA_property_float_get(&but->rnapoin, but->rnaprop);
Cleaning i18n code. Previous state: Right now, there are "memories" of the "old" (less than a month!) translation way: * A few remaining calls to BLF_gettext() (only UI_translate_do_iface and UI_translate_do_tooltip should be used). * The _() macro still also calls BLF_gettext()! New state: Here are the changes made by the patch: * Removing the no more needed _() macro. * Removing most N_() and _() calls, only keeping the few needed ones (i.e. strings that are in no other way findable by xgettext and/or update_msg script). * Defining in UI_interface.h IFACE_() and TIP_() macros (resp. for UI_translate_do_iface and UI_translate_do_tooltip). * Replacing all calls to BLF_gettext by relevant IFACE_ or TIP_ one. * Replacing all calls to UI_translate_do_iface by IFACE_. * Replacing all calls to UI_translate_do_tooltip by TIP_. All this somewhat clarifies and simplifies the code. On the bf-translations scripts side, this only implies adding IFACE_ and TIP_ as detection markers for xgettext. It also allows to reduce POTFILES.in quite notably (only 20 files remaining in it). Please also have a look at those pages: * Coder POV: http://wiki.blender.org/index.php/Dev:2.5/Source/Interface/Internationalization * Translator POV: http://wiki.blender.org/index.php/Dev:2.5/Doc/How_to/Translate_Blender
2011-10-20 20:38:26 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Radians: %f"), value);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].color_id = UI_TIP_LC_NORMAL;
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
data->totline++;
}
}
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->flag & UI_BUT_DRIVEN) {
if (ui_but_anim_expression_get(but, buf, sizeof(buf))) {
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
/* expression */
Cleaning i18n code. Previous state: Right now, there are "memories" of the "old" (less than a month!) translation way: * A few remaining calls to BLF_gettext() (only UI_translate_do_iface and UI_translate_do_tooltip should be used). * The _() macro still also calls BLF_gettext()! New state: Here are the changes made by the patch: * Removing the no more needed _() macro. * Removing most N_() and _() calls, only keeping the few needed ones (i.e. strings that are in no other way findable by xgettext and/or update_msg script). * Defining in UI_interface.h IFACE_() and TIP_() macros (resp. for UI_translate_do_iface and UI_translate_do_tooltip). * Replacing all calls to BLF_gettext by relevant IFACE_ or TIP_ one. * Replacing all calls to UI_translate_do_iface by IFACE_. * Replacing all calls to UI_translate_do_tooltip by TIP_. All this somewhat clarifies and simplifies the code. On the bf-translations scripts side, this only implies adding IFACE_ and TIP_ as detection markers for xgettext. It also allows to reduce POTFILES.in quite notably (only 20 files remaining in it). Please also have a look at those pages: * Coder POV: http://wiki.blender.org/index.php/Dev:2.5/Source/Interface/Internationalization * Translator POV: http://wiki.blender.org/index.php/Dev:2.5/Doc/How_to/Translate_Blender
2011-10-20 20:38:26 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Expression: %s"), buf);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].color_id = UI_TIP_LC_NORMAL;
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
data->totline++;
}
}
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
ID *id = but->rnapoin.id.data;
remove NULL checks on fixed size arrays, also was calling BLI_testextensie_glob every time in the file selector with a blank string.
2013-07-13 14:16:59 +00:00
if (id->lib) {
Cleaning i18n code. Previous state: Right now, there are "memories" of the "old" (less than a month!) translation way: * A few remaining calls to BLF_gettext() (only UI_translate_do_iface and UI_translate_do_tooltip should be used). * The _() macro still also calls BLF_gettext()! New state: Here are the changes made by the patch: * Removing the no more needed _() macro. * Removing most N_() and _() calls, only keeping the few needed ones (i.e. strings that are in no other way findable by xgettext and/or update_msg script). * Defining in UI_interface.h IFACE_() and TIP_() macros (resp. for UI_translate_do_iface and UI_translate_do_tooltip). * Replacing all calls to BLF_gettext by relevant IFACE_ or TIP_ one. * Replacing all calls to UI_translate_do_iface by IFACE_. * Replacing all calls to UI_translate_do_tooltip by TIP_. All this somewhat clarifies and simplifies the code. On the bf-translations scripts side, this only implies adding IFACE_ and TIP_ as detection markers for xgettext. It also allows to reduce POTFILES.in quite notably (only 20 files remaining in it). Please also have a look at those pages: * Coder POV: http://wiki.blender.org/index.php/Dev:2.5/Source/Interface/Internationalization * Translator POV: http://wiki.blender.org/index.php/Dev:2.5/Doc/How_to/Translate_Blender
2011-10-20 20:38:26 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Library: %s"), id->lib->name);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].color_id = UI_TIP_LC_NORMAL;
merge own commits into render branch into trunk since 27560 27562, 27570, 27571, 27574, 27576, 27577, 27579, 27590, 27591, 27594, 27595, 27596, 27599, 27605, 27611, 27612, 27613, 27614, 27623
2010-03-20 16:41:01 +00:00
data->totline++;
}
}
- include operator commands in tooltips (needs sanitizing for transform operators, there are massive :|) - WM_operator_pystring can now be used with an operator type and properties (rather then a wmOperator instance) - removed menus from file selector
2009-07-29 23:12:30 +00:00
}
else if (but->optype) {
PointerRNA *opptr;
char *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
opptr = UI_but_operator_ptr_get(but); /* allocated when needed, the button owns it */
- include operator commands in tooltips (needs sanitizing for transform operators, there are massive :|) - WM_operator_pystring can now be used with an operator type and properties (rather then a wmOperator instance) - removed menus from file selector
2009-07-29 23:12:30 +00:00
fix for crash showing tooltip for NODE_OT_add_search()
2012-08-17 11:31:54 +00:00
/* so the context is passed to itemf functions (some py itemf functions use it) */
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
WM_operator_properties_sanitize(opptr, false);
fix for crash showing tooltip for NODE_OT_add_search()
2012-08-17 11:31:54 +00:00
User Interface: don't show macro args in tooltips was often making much too big strings to show in a tip.
2013-11-26 08:59:14 +11:00
str = WM_operator_pystring_ex(C, NULL, false, false, but->optype, opptr);
- include operator commands in tooltips (needs sanitizing for transform operators, there are massive :|) - WM_operator_pystring can now be used with an operator type and properties (rather then a wmOperator instance) - removed menus from file selector
2009-07-29 23:12:30 +00:00
Tooltips: abbreviate long python operator tooltips Some tooltips would end up containing long string/array args spanning the screen.
2013-12-09 14:20:53 +11:00
/* avoid overly verbose tips (eg, arrays of 20 layers), exact limit is arbitrary */
WM_operator_pystring_abbreviate(str, 32);
- include operator commands in tooltips (needs sanitizing for transform operators, there are massive :|) - WM_operator_pystring can now be used with an operator type and properties (rather then a wmOperator instance) - removed menus from file selector
2009-07-29 23:12:30 +00:00
/* operator info */
User preference to hide Python references in Tooltips.
2010-11-22 00:10:32 +00:00
if ((U.flag & USER_TOOLTIPS_PYTHON) == 0) {
Cleaning i18n code. Previous state: Right now, there are "memories" of the "old" (less than a month!) translation way: * A few remaining calls to BLF_gettext() (only UI_translate_do_iface and UI_translate_do_tooltip should be used). * The _() macro still also calls BLF_gettext()! New state: Here are the changes made by the patch: * Removing the no more needed _() macro. * Removing most N_() and _() calls, only keeping the few needed ones (i.e. strings that are in no other way findable by xgettext and/or update_msg script). * Defining in UI_interface.h IFACE_() and TIP_() macros (resp. for UI_translate_do_iface and UI_translate_do_tooltip). * Replacing all calls to BLF_gettext by relevant IFACE_ or TIP_ one. * Replacing all calls to UI_translate_do_iface by IFACE_. * Replacing all calls to UI_translate_do_tooltip by TIP_. All this somewhat clarifies and simplifies the code. On the bf-translations scripts side, this only implies adding IFACE_ and TIP_ as detection markers for xgettext. It also allows to reduce POTFILES.in quite notably (only 20 files remaining in it). Please also have a look at those pages: * Coder POV: http://wiki.blender.org/index.php/Dev:2.5/Source/Interface/Internationalization * Translator POV: http://wiki.blender.org/index.php/Dev:2.5/Doc/How_to/Translate_Blender
2011-10-20 20:38:26 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Python: %s"), str);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].style = UI_TIP_STYLE_MONO;
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_PYTHON;
User preference to hide Python references in Tooltips.
2010-11-22 00:10:32 +00:00
data->totline++;
}
- include operator commands in tooltips (needs sanitizing for transform operators, there are massive :|) - WM_operator_pystring can now be used with an operator type and properties (rather then a wmOperator instance) - removed menus from file selector
2009-07-29 23:12:30 +00:00
MEM_freeN(str);
bugfix [#24179] Button "Loop Cut and Slide" on Mesh Tools not work also added a message in the tooltip to say `why` a buttons disabled. depends on the operators poll setting the message.
2010-10-08 11:33:10 +00:00
/* second check if we are disabled - why */
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->flag & UI_BUT_DISABLED) {
bugfix [#24179] Button "Loop Cut and Slide" on Mesh Tools not work also added a message in the tooltip to say `why` a buttons disabled. depends on the operators poll setting the message.
2010-10-08 11:33:10 +00:00
const char *poll_msg;
CTX_wm_operator_poll_msg_set(C, NULL);
fix to allow [#24009] to be fixed. WM_operator_poll() could fail in cases WM_operator_name_call() would succeed because calling the operator would setup the context before calling poll. this would result in python raising an invalid error or menu items being greyed out. now python can also check with an operator context: bpy.ops.object.editmode_toggle.poll('INVOKE_SCREEN')
2010-11-04 12:59:03 +00:00
WM_operator_poll_context(C, but->optype, but->opcontext);
style cleanup: interface
2012-03-30 01:51:25 +00:00
poll_msg = CTX_wm_operator_poll_msg_get(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 (poll_msg) {
Cleaning i18n code. Previous state: Right now, there are "memories" of the "old" (less than a month!) translation way: * A few remaining calls to BLF_gettext() (only UI_translate_do_iface and UI_translate_do_tooltip should be used). * The _() macro still also calls BLF_gettext()! New state: Here are the changes made by the patch: * Removing the no more needed _() macro. * Removing most N_() and _() calls, only keeping the few needed ones (i.e. strings that are in no other way findable by xgettext and/or update_msg script). * Defining in UI_interface.h IFACE_() and TIP_() macros (resp. for UI_translate_do_iface and UI_translate_do_tooltip). * Replacing all calls to BLF_gettext by relevant IFACE_ or TIP_ one. * Replacing all calls to UI_translate_do_iface by IFACE_. * Replacing all calls to UI_translate_do_tooltip by TIP_. All this somewhat clarifies and simplifies the code. On the bf-translations scripts side, this only implies adding IFACE_ and TIP_ as detection markers for xgettext. It also allows to reduce POTFILES.in quite notably (only 20 files remaining in it). Please also have a look at those pages: * Coder POV: http://wiki.blender.org/index.php/Dev:2.5/Source/Interface/Internationalization * Translator POV: http://wiki.blender.org/index.php/Dev:2.5/Doc/How_to/Translate_Blender
2011-10-20 20:38:26 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Disabled: %s"), poll_msg);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].color_id = UI_TIP_LC_ALERT;
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
data->totline++;
bugfix [#24179] Button "Loop Cut and Slide" on Mesh Tools not work also added a message in the tooltip to say `why` a buttons disabled. depends on the operators poll setting the message.
2010-10-08 11:33:10 +00:00
}
}
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
}
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 ((U.flag & USER_TOOLTIPS_PYTHON) == 0 && !but->optype && rna_struct.strinfo) {
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
if (rna_prop.strinfo) {
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
/* Struct and prop */
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]),
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
TIP_("Python: %s.%s"),
rna_struct.strinfo, rna_prop.strinfo);
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
}
else {
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
/* Only struct (e.g. menus) */
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
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]),
TIP_("Python: %s"), rna_struct.strinfo);
}
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].style = UI_TIP_STYLE_MONO;
data->format[data->totline].is_pad = true;
data->format[data->totline].color_id = UI_TIP_LC_PYTHON;
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
data->totline++;
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
if (but->rnapoin.id.data) {
/* this could get its own 'BUT_GET_...' type */
/* never fails */
RNA: de-duplciate rna-path create in tooltip code
2015-11-30 22:38:39 +11:00
char *id_path;
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
RNA: de-duplciate rna-path create in tooltip code
2015-11-30 22:38:39 +11:00
if (but->rnaprop) {
id_path = RNA_path_full_property_py_ex(&but->rnapoin, but->rnaprop, but->rnaindex, true);
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
}
RNA: de-duplciate rna-path create in tooltip code
2015-11-30 22:38:39 +11:00
else {
id_path = RNA_path_full_struct_py(&but->rnapoin);
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
}
RNA: de-duplciate rna-path create in tooltip code
2015-11-30 22:38:39 +11:00
BLI_strncat_utf8(data->lines[data->totline], id_path, sizeof(data->lines[0]));
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
MEM_freeN(id_path);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->format[data->totline].style = UI_TIP_STYLE_MONO;
data->format[data->totline].color_id = UI_TIP_LC_PYTHON;
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
data->totline++;
}
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
}
/* Free strinfo's... */
if (but_tip.strinfo)
MEM_freeN(but_tip.strinfo);
if (enum_label.strinfo)
MEM_freeN(enum_label.strinfo);
if (enum_tip.strinfo)
MEM_freeN(enum_tip.strinfo);
if (op_keymap.strinfo)
MEM_freeN(op_keymap.strinfo);
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 (prop_keymap.strinfo)
MEM_freeN(prop_keymap.strinfo);
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 (rna_struct.strinfo)
MEM_freeN(rna_struct.strinfo);
if (rna_prop.strinfo)
MEM_freeN(rna_prop.strinfo);
2.5: UI * Fix issue where it would automatically scroll when collapsing panels. * Fix panel dragging not taking zoom level into account. * Fix enum menu having too small default width in headers. * Fix tooltips not showing shortcuts etc. if there was not tooltip defined for the button. * Fix some refresh issues with color ramps. * Add a bit more space between columns in the layout engine. * Make scrollers darker so they are less distracting, and highlight instead of reverse shading when dragging.
2009-07-23 20:50:24 +00:00
There was no way of knowing what ID type a property comes from by the tooltip, (since copying the Data-Path doesn't include the ID the user had to guess). Now include the full python path to the property in the tool-tip.
2012-12-02 07:13:19 +00:00
BLI_assert(data->totline < MAX_TOOLTIP_LINES);
bugfix [#24179] Button "Loop Cut and Slide" on Mesh Tools not work also added a message in the tooltip to say `why` a buttons disabled. depends on the operators poll setting the message.
2010-10-08 11:33:10 +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 (data->totline == 0) {
2.5: UI * Fix issue where it would automatically scroll when collapsing panels. * Fix panel dragging not taking zoom level into account. * Fix enum menu having too small default width in headers. * Fix tooltips not showing shortcuts etc. if there was not tooltip defined for the button. * Fix some refresh issues with color ramps. * Add a bit more space between columns in the layout engine. * Make scrollers darker so they are less distracting, and highlight instead of reverse shading when dragging.
2009-07-23 20:50:24 +00:00
MEM_freeN(data);
return NULL;
}
/* create area 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
ar = ui_region_temp_add(CTX_wm_screen(C));
2.5: UI * Fix issue where it would automatically scroll when collapsing panels. * Fix panel dragging not taking zoom level into account. * Fix enum menu having too small default width in headers. * Fix tooltips not showing shortcuts etc. if there was not tooltip defined for the button. * Fix some refresh issues with color ramps. * Add a bit more space between columns in the layout engine. * Make scrollers darker so they are less distracting, and highlight instead of reverse shading when dragging.
2009-07-23 20:50:24 +00:00
memset(&type, 0, sizeof(ARegionType));
style cleanup: interface
2012-03-30 01:51:25 +00:00
type.draw = ui_tooltip_region_draw_cb;
type.free = ui_tooltip_region_free_cb;
Fix #35880: popup menus like F6 redo did not use the right theme color for highlighted text, it should use the UI instead of 3D view color.
2013-06-26 12:24:36 +00:00
type.regionid = RGN_TYPE_TEMPORARY;
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->type = &type;
2.5 Grand cleanup: - removal of FTF and ftfont dir - removal of text.c which wrapped it - wrapped old text drawing code temporarily, need to decide how 'style' will behave per editor when you draw strings outside interface code.... wouldn't be very useful to set fonts locally all over?
2009-04-10 16:30:28 +00:00
/* set font, get bb */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->fstyle = style->widget; /* copy struct */
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
ui_fontscale(&data->fstyle.points, aspect);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(&data->fstyle);
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
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
data->wrap_width = min_ii(UI_TIP_MAXWIDTH * U.pixelsize / aspect, WM_window_pixels_x(win) - (UI_TIP_PADDING * 2));
font_flag |= BLF_WORD_WRAP;
if (data->fstyle.kerning == 1) {
font_flag |= BLF_KERNING_DEFAULT;
}
BLF_enable(data->fstyle.uifont_id, font_flag);
BLF_enable(blf_mono_font, font_flag);
BLF_wordwrap(data->fstyle.uifont_id, data->wrap_width);
BLF_wordwrap(blf_mono_font, data->wrap_width);
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
/* these defines tweaked depending on font */
#define TIP_BORDER_X (16.0f / aspect)
#define TIP_BORDER_Y (6.0f / aspect)
new BLF functions - BLF_height_max - BLF_width_max - BLF_descender - BLF_ascender use for tooltip and image stamp.
2011-05-04 15:09:48 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
h = BLF_height_max(data->fstyle.uifont_id);
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
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
for (i = 0, fontw = 0, fonth = 0; i < data->totline; i++) {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
struct ResultBLF info;
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
int w, x_pos = 0;
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
if (data->format[i].style == UI_TIP_STYLE_HEADER) {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
w = BLF_width_ex(data->fstyle.uifont_id, data->header, sizeof(data->header), &info);
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
if (enum_label.strinfo) {
x_pos = info.width + (U.widget_unit / 2);
w = max_ii(w, x_pos + BLF_width(data->fstyle.uifont_id, data->active_info, sizeof(data->active_info)));
}
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
else if (data->format[i].style == UI_TIP_STYLE_MONO) {
BLF_size(blf_mono_font, data->fstyle.points * U.pixelsize, U.dpi);
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
w = BLF_width_ex(blf_mono_font, data->lines[i], sizeof(data->lines[i]), &info);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
else {
BLI_assert(data->format[i].style == UI_TIP_STYLE_NORMAL);
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
w = BLF_width_ex(data->fstyle.uifont_id, data->lines[i], sizeof(data->lines[i]), &info);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
fontw = max_ii(fontw, w);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
fonth += h * info.lines;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
if ((i + 1 != data->totline) && data->format[i + 1].is_pad) {
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
fonth += h * (UI_TIP_PAD_FAC - 1);
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
}
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
data->line_geom[i].lines = info.lines;
UI: tooltip layout tweaks - enable word-wrap for all tip text to align vertically. - draw enum identifier at the end of the last line, not first.
2015-09-19 15:11:57 +10:00
data->line_geom[i].x_pos = x_pos;
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
}
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
//fontw *= aspect;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: word-wrap support for tooltips Tooltips will automatically wrap when exceeding UI_TIP_MAXWIDTH.
2015-09-18 20:21:25 +10:00
BLF_disable(data->fstyle.uifont_id, font_flag);
BLF_disable(blf_mono_font, font_flag);
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->regiondata = data;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->toth = fonth;
data->lineh = h;
new BLF functions - BLF_height_max - BLF_width_max - BLF_descender - BLF_ascender use for tooltip and image stamp.
2011-05-04 15:09:48 +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
/* compute position */
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
ofsx = 0; //(but->block->panel) ? but->block->panel->ofsx : 0;
ofsy = 0; //(but->block->panel) ? but->block->panel->ofsy : 0;
code cleanup: - cycles ui used 'cscene' for scene.cycles and scene.cycles_curves - style cleanup
2013-01-15 23:17:45 +00:00
rect_fl.xmin = BLI_rctf_cent_x(&but->rect) + ofsx - TIP_BORDER_X;
UI: tooltips, blurry and incorrect rhs-padding in recent update D634 by Severin
2014-07-07 10:43:32 +10:00
rect_fl.xmax = rect_fl.xmin + fontw + pad_px;
style cleanup: casts, some casts had odd formatting, but very few. Style checker script detects this now so easy to detect this if new code is added that doesnt follow blenders style.
2012-12-30 15:16:08 +00:00
rect_fl.ymax = but->rect.ymin + ofsy - TIP_BORDER_Y;
rect_fl.ymin = rect_fl.ymax - fonth - TIP_BORDER_Y;
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
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
/* since the text has beens caled already, the size of tooltips is defined now */
/* here we try to figure out the right location */
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 (butregion) {
UI: use cursor x-location for tooltip placement (T37478)
2014-06-27 22:56:31 +10:00
float mx, my;
code cleanup: quiet some -Wshadow warnings, mix of obvious mistakes and harmless global/local naming conflict.
2013-03-15 22:55:10 +00:00
float ofsx_fl = rect_fl.xmin, ofsy_fl = rect_fl.ymax;
ui_block_to_window_fl(butregion, but->block, &ofsx_fl, &ofsy_fl);
UI: use cursor x-location for tooltip placement (T37478)
2014-06-27 22:56:31 +10:00
#if 1
/* use X mouse location */
mx = (win->eventstate->x + (TIP_BORDER_X * 2)) - BLI_rctf_cent_x(&but->rect);
#else
mx = ofsx_fl - rect_fl.xmin;
#endif
my = ofsy_fl - rect_fl.ymax;
BLI_rctf_translate(&rect_fl, mx, my);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
BLI_rcti_rctf_copy(&rect_i, &rect_fl);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: use cursor x-location for tooltip placement (T37478)
2014-06-27 22:56:31 +10:00
#undef TIP_BORDER_X
#undef TIP_BORDER_Y
Bugfix #33458 Tooltips in Blender were not scaling when zooming in/out on UI elements. (They did follow DPI though, but tooltips were in a 'global' fixed size). Error was that for tooltips on large scaled popups (like in Node editor) the drawing was entirely wrong even. Now tooltips scale correctly, also for fonts.
2012-12-16 13:31:56 +00:00
/* clip with window boundaries */
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
winx = WM_window_pixels_x(win);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if (rect_i.xmax > winx) {
2.5 - Tooltips now respect view2d view (rna viewer). - Bugfix in viewd.c UI_view2d_view_to_region() (typo)
2008-12-03 17:11:50 +00:00
/* super size */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (rect_i.xmax > winx + rect_i.xmin) {
rect_i.xmax = winx;
rect_i.xmin = 0;
2.5 - Tooltips now respect view2d view (rna viewer). - Bugfix in viewd.c UI_view2d_view_to_region() (typo)
2008-12-03 17:11:50 +00:00
}
else {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rect_i.xmin -= rect_i.xmax - winx;
rect_i.xmax = winx;
2.5 - Tooltips now respect view2d view (rna viewer). - Bugfix in viewd.c UI_view2d_view_to_region() (typo)
2008-12-03 17:11:50 +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
}
tooltips were part way of the bottom of the screen (timeline play button for eg)
2011-04-05 12:05:47 +00:00
/* ensure at least 5 px above screen bounds
* 25 is just a guess to be above the menu item */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (rect_i.ymin < 5) {
rect_i.ymax += (-rect_i.ymin) + 30;
rect_i.ymin = 30;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
/* add padding */
BLI_rcti_resize(&rect_i,
BLI_rcti_size_x(&rect_i) + pad_px,
BLI_rcti_size_y(&rect_i) + pad_px);
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
/* widget rect, in region coords */
UI todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50:39 +00:00
{
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
const int margin = UI_POPUP_MARGIN;
UI todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50:39 +00:00
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
data->bbox.xmin = margin;
data->bbox.xmax = BLI_rcti_size_x(&rect_i) - margin;
data->bbox.ymin = margin;
Update the design of tooltips - left aligned - higher contrast between tip text and py-text - use monospace for py-text D611 by Severin, design by Plyczkowski, with own minor changes.
2014-06-24 19:00:02 +10:00
data->bbox.ymax = BLI_rcti_size_y(&rect_i);
UI todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50:39 +00:00
/* region bigger for shadow */
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
ar->winrct.xmin = rect_i.xmin - margin;
ar->winrct.xmax = rect_i.xmax + margin;
ar->winrct.ymin = rect_i.ymin - margin;
ar->winrct.ymax = rect_i.ymax + margin;
UI todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50: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
2.5 Cleanup in area/region management - more intelligence in area management for adding handlers and setting data correct. Space/Region type callbacks only have to do own things. - added option for adding default handlers to areas/regions. (flag in type definition) - ensured that region-types store the minsizes for regions. - added boundbox check for handlers; note that it accepts pointer to boundbox, because handlers don't get reset on area-resizing or view changes. Example: view2d handlers use mask rect. - handlers get now added on correct context levels (example frame change also worked in header) - removed ->refresh() callback. Context refreshing is Listener. - the ->init() is being called on all WM level actions, also after a file read, moving areas, re-opening areas etc. - fixed bug: crash on exit was caused by cleaning up Screen too late. - UI_view2d_size_update() removed from draw callback, is init() - regions now store (winx, winy) subwindow size.
2008-12-10 13:56:54 +00:00
/* adds subwindow */
ED_region_init(C, 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
/* notify change and redraw */
2.5 Work on getting notifiers in shape. - Most important: local (to own region or area) redraw notifiers have been depricated. This is not a good or correct notifier anyway. Notifiers should be signals to other areas. - Instead use these 2 functions: ED_area_tag_redraw(area); ED_region_tag_redraw(region); It seems to me good convention to keep the area/region redraw tag itself protected everywhere, for future improvements. - Also added a basic WM function that checks overlapping regions, and flushes redraws to underlying regions. This makes menus and buttons allow to only send local region redraws. (Brought back two "swapbuffer indicators" to test this. - Todo: area 'action zone' redraws, and fixing other notifiers... sending data pointers in a notifier seems to be bad idea.
2008-12-16 12:28:00 +00:00
ED_region_tag_redraw(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
return ar;
}
void ui_tooltip_free(bContext *C, ARegion *ar)
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_region_temp_remove(C, CTX_wm_screen(C), 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
}
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
/************************* Creating Search Box **********************/
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
struct uiSearchItems {
int maxitem, totitem, maxstrlen;
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
int offset, offset_i; /* offset for inserting in array */
int more; /* flag indicating there are more items */
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
char **names;
void **pointers;
2.5 Added support for icons in search menu. It already displays icons for saved materials etc. from old files. Have to add previewrenders for this still.
2009-06-24 16:44:54 +00:00
int *icons;
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
AutoComplete *autocpl;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
void *active;
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
};
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
typedef struct uiSearchboxData {
rcti bbox;
uiFontStyle fstyle;
uiSearchItems items;
style cleanup: interface
2012-03-30 01:51:25 +00:00
int active; /* index in items array */
code cleanup: use bools, (float)sin/(float)cos -> sinf/cosf, more meaningful var names.
2013-04-04 04:22:38 +00:00
bool noback; /* when menu opened with enough space for this */
bool preview; /* draw thumbnail previews, rather than list */
interface, replace '|' with define UI_SEP_CHAR
2013-09-11 05:06:27 +00:00
bool use_sep; /* use the UI_SEP_CHAR char for splitting shortcuts (good for operators, bad for data) */
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
int prv_rows, prv_cols;
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
} uiSearchboxData;
style cleanup: interface
2012-03-30 01:51:25 +00:00
#define SEARCH_ITEMS 10
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
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
/* exported for use by search callbacks */
/* returns zero if nothing to add */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_search_item_add(uiSearchItems *items, const char *name, void *poin, int iconid)
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 * 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
/* hijack for autocomplete */
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 (items->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
UI_autocomplete_update_name(items->autocpl, name);
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 * 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
}
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
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
/* hijack for finding active item */
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 (items->active) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (poin == items->active)
items->offset_i = items->totitem;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
items->totitem++;
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 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (items->totitem >= items->maxitem) {
items->more = 1;
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 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
/* skip first items in list */
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 (items->offset_i > 0) {
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
items->offset_i--;
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 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (items->names)
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
BLI_strncpy(items->names[items->totitem], name, items->maxstrlen);
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 (items->pointers)
style cleanup: interface
2012-03-30 01:51:25 +00:00
items->pointers[items->totitem] = poin;
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 (items->icons)
style cleanup: interface
2012-03-30 01:51:25 +00:00
items->icons[items->totitem] = iconid;
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
items->totitem++;
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 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
int UI_searchbox_size_y(void)
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
{
UI: expose UI_POPUP_MENU_TOP for use elsewhere.
2015-10-17 00:21:35 +11:00
return SEARCH_ITEMS * UI_UNIT_Y + 2 * UI_POPUP_MENU_TOP;
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
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
int UI_searchbox_size_x(void)
search box width's now scale with DPI setting. was checking on: [#33294] too small place for material names this helps in some cases but doesn't resolve issue with very long names.
2012-11-26 13:23:37 +00:00
{
Fix T38678: Long strings on Search widget not getting shortened/no tooltip. Note this commit only makes search menus wider and adds shortening to their strings. Adding tooltips here is not trivial, would need much bigger changes... Reviewers: brecht Reviewed By: brecht Differential Revision: https://developer.blender.org/D341
2014-02-26 21:53:56 +01:00
return 12 * UI_UNIT_X;
search box width's now scale with DPI setting. was checking on: [#33294] too small place for material names this helps in some cases but doesn't resolve issue with very long names.
2012-11-26 13:23: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
int UI_search_items_find_index(uiSearchItems *items, const char *name)
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
{
int i;
for (i = 0; i < items->totitem; i++) {
if (STREQ(name, items->names[i])) {
return i;
}
}
return -1;
}
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
/* ar is the search box itself */
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
static void ui_searchbox_select(bContext *C, ARegion *ar, uiBut *but, int step)
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
uiSearchboxData *data = ar->regiondata;
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
/* apply step */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->active += step;
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
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
if (data->items.totitem == 0) {
data->active = -1;
}
else if (data->active >= data->items.totitem) {
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 (data->items.more) {
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
data->items.offset++;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = data->items.totitem - 1;
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
ui_searchbox_update(C, ar, but, false);
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
else {
data->active = data->items.totitem - 1;
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
else if (data->active < 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 (data->items.offset) {
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
data->items.offset--;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = 0;
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
ui_searchbox_update(C, ar, but, false);
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
UI: Disable operator search menu setting an unset state key key-input
2014-09-10 19:22:29 +10:00
else {
/* only let users step into an 'unset' state for unlink buttons */
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
data->active = (but->flag & UI_BUT_SEARCH_UNLINK) ? -1 : 0;
UI: Disable operator search menu setting an unset state key key-input
2014-09-10 19:22:29 +10:00
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
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
ED_region_tag_redraw(ar);
}
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
static void ui_searchbox_butrect(rcti *r_rect, uiSearchboxData *data, int itemnr)
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
{
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
/* thumbnail preview */
if (data->preview) {
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
int butw = (BLI_rcti_size_x(&data->bbox) - 2 * MENU_BORDER) / data->prv_cols;
int buth = (BLI_rcti_size_y(&data->bbox) - 2 * MENU_BORDER) / data->prv_rows;
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
int row, col;
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
*r_rect = data->bbox;
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
col = itemnr % data->prv_cols;
row = itemnr / data->prv_cols;
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
r_rect->xmin += MENU_BORDER + (col * butw);
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
r_rect->xmax = r_rect->xmin + butw;
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
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
r_rect->ymax -= MENU_BORDER + (row * buth);
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
r_rect->ymin = r_rect->ymax - buth;
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
}
/* list view */
else {
UI: expose UI_POPUP_MENU_TOP for use elsewhere.
2015-10-17 00:21:35 +11:00
int buth = (BLI_rcti_size_y(&data->bbox) - 2 * UI_POPUP_MENU_TOP) / SEARCH_ITEMS;
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
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
*r_rect = data->bbox;
r_rect->xmin = data->bbox.xmin + 3.0f;
r_rect->xmax = data->bbox.xmax - 3.0f;
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
UI: expose UI_POPUP_MENU_TOP for use elsewhere.
2015-10-17 00:21:35 +11:00
r_rect->ymax = data->bbox.ymax - UI_POPUP_MENU_TOP - itemnr * buth;
Code Cleanup: pass rectangles as const in insterface files
2013-12-07 15:47:57 +11:00
r_rect->ymin = r_rect->ymax - buth;
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
}
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
}
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
int ui_searchbox_find_index(ARegion *ar, const char *name)
{
uiSearchboxData *data = ar->regiondata;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_search_items_find_index(&data->items, name);
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
}
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* x and y in screencoords */
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 ui_searchbox_inside(ARegion *ar, int x, int y)
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +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 BLI_rcti_isect_pt(&data->bbox, x - ar->winrct.xmin, y - ar->winrct.ymin);
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
}
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
/* string validated to be of correct length (but->hardmax) */
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
bool ui_searchbox_apply(uiBut *but, ARegion *ar)
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
uiSearchboxData *data = ar->regiondata;
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->func_arg2 = NULL;
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
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
if (data->active != -1) {
const char *name = data->items.names[data->active];
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
const char *name_sep = data->use_sep ? strrchr(name, UI_SEP_CHAR) : NULL;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
BLI_strncpy(but->editstr, name, name_sep ? (name_sep - name) : data->items.maxstrlen);
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
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
but->func_arg2 = data->items.pointers[data->active];
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
return true;
}
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->flag & UI_BUT_SEARCH_UNLINK) {
Fix two bugs with searchbox UI items. First one, reported by Sergey, was searchbox not closing when validating it (enter or LMB click) without any active item (we need to enable escapecancel here, to close menu too). Second one was SEARCH_MENU_UNLINK variant not unlinking at validation when no active item. Thanks a bunch to Campbell for help here!
2014-09-10 12:53:22 +02:00
/* It is valid for _UNLINK flavor to have no active element (it's a valid way to unlink). */
but->editstr[0] = '\0';
return true;
}
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
else {
return false;
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
}
}
code cleanup: make wmEvent's 'const' in interface code (reduces manual checking that they are not modified).
2013-02-01 01:01:20 +00:00
void ui_searchbox_event(bContext *C, ARegion *ar, uiBut *but, const wmEvent *event)
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
uiSearchboxData *data = ar->regiondata;
Further trackpad work: When trackpad swipes don't convert to ScrollWheel steps anymore, several hardcoded wheel events need to support swipe too. This adds swipe support to: - Menu item scroll - Search item scroll - ALT + number/slider/swatch values The amount of old style scroll "clicks" is calculated based on how trackad is being mapped to move a mouse pointer. Move it one widget unit = 1 click. The swatch option applies trackpad swipe motion in analog way.
2013-01-01 16:42:35 +00:00
int type = event->type, val = event->val;
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
Further trackpad work: When trackpad swipes don't convert to ScrollWheel steps anymore, several hardcoded wheel events need to support swipe too. This adds swipe support to: - Menu item scroll - Search item scroll - ALT + number/slider/swatch values The amount of old style scroll "clicks" is calculated based on how trackad is being mapped to move a mouse pointer. Move it one widget unit = 1 click. The swatch option applies trackpad swipe motion in analog way.
2013-01-01 16:42:35 +00:00
if (type == MOUSEPAN)
ui_pan_to_scroll(event, &type, &val);
switch (type) {
2.5 Several usablity tweaks: - Search menu allows ScrollWheel to view items - Tooltip on button on bottom of window showed wrong - Tooltips were popping up while draggin (MMB) or scrolling (wheel). Now they stay away. - Stolen from Gimp (blame venomgfx for hint!): ScrollWheel allows to go over menu items and use number buttons, only on mouse-over. Note for devs: the WM_event_add_mousemove() call (to add a fake event to bring UI back alive after view changes) now works much more reliably. It ensures the mouse move is only handled after all notifiers/redraws were done.
2009-06-06 13:35:04 +00:00
case WHEELUPMOUSE:
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
case UPARROWKEY:
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
ui_searchbox_select(C, ar, but, -1);
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
break;
2.5 Several usablity tweaks: - Search menu allows ScrollWheel to view items - Tooltip on button on bottom of window showed wrong - Tooltips were popping up while draggin (MMB) or scrolling (wheel). Now they stay away. - Stolen from Gimp (blame venomgfx for hint!): ScrollWheel allows to go over menu items and use number buttons, only on mouse-over. Note for devs: the WM_event_add_mousemove() call (to add a fake event to bring UI back alive after view changes) now works much more reliably. It ensures the mouse move is only handled after all notifiers/redraws were done.
2009-06-06 13:35:04 +00:00
case WHEELDOWNMOUSE:
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
case DOWNARROWKEY:
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
ui_searchbox_select(C, ar, but, 1);
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
break;
case MOUSEMOVE:
code cleanup: rename BLI_in_rctf() --> BLI_rctf_isect_pt(), to conform with our naming convention.
2012-08-23 18:25:45 +00:00
if (BLI_rcti_isect_pt(&ar->winrct, event->x, event->y)) {
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
rcti rect;
int a;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < data->items.totitem; a++) {
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_searchbox_butrect(&rect, data, a);
code cleanup: rename BLI_in_rctf() --> BLI_rctf_isect_pt(), to conform with our naming convention.
2012-08-23 18:25:45 +00:00
if (BLI_rcti_isect_pt(&rect, event->x - ar->winrct.xmin, event->y - ar->winrct.ymin)) {
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
if (data->active != a) {
data->active = a;
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
ui_searchbox_select(C, ar, but, 0);
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
break;
}
}
}
}
break;
}
}
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
/* ar is the search box itself */
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_searchbox_update(bContext *C, ARegion *ar, uiBut *but, const bool reset)
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: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
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
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
/* reset vars */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.totitem = 0;
data->items.more = 0;
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
if (reset == false) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset_i = data->items.offset;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset_i = data->items.offset = 0;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = -1;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
/* handle active */
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->search_func && but->func_arg2) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.active = but->func_arg2;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
but->search_func(C, but->search_arg, but->editstr, &data->items);
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.active = NULL;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
/* found active item, calculate real offset by centering it */
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 (data->items.totitem) {
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
/* first case, begin of list */
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 (data->items.offset_i < data->items.maxitem) {
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = data->items.offset_i;
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset_i = 0;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
else {
/* second case, end of list */
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 (data->items.totitem - data->items.offset_i <= data->items.maxitem) {
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = data->items.offset_i - data->items.totitem + data->items.maxitem;
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset_i = data->items.totitem - data->items.maxitem;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
else {
/* center active item */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset_i -= data->items.maxitem / 2;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = data->items.maxitem / 2;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
}
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.offset = data->items.offset_i;
data->items.totitem = 0;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
/* callback */
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->search_func)
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
but->search_func(C, but->search_arg, but->editstr, &data->items);
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
/* handle case where editstr is equal to one of items */
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
if (reset && data->active == -1) {
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
int a;
2.5 Search Menu: added feature that on opening, it shows the current ID block, and selects it. Same can be used for other searches, just pass on pointer to active item for the search callback. Also fixed arrow triangle draw for search.
2009-06-29 11:29:52 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < data->items.totitem; a++) {
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
const char *name = data->items.names[a];
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
const char *name_sep = data->use_sep ? strrchr(name, UI_SEP_CHAR) : NULL;
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
if (STREQLEN(but->editstr, name, name_sep ? (name_sep - name) : data->items.maxstrlen)) {
data->active = a;
break;
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (data->items.totitem == 1 && but->editstr[0])
internal change to searchbox: store the active search index rather then index + 1, simplifies checks.
2013-06-13 01:13:26 +00:00
data->active = 0;
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
}
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
/* validate selected item */
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
ui_searchbox_select(C, ar, but, 0);
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
ED_region_tag_redraw(ar);
}
File Browser: autocomplete keeps focus in the file field when entering a folder. There is a bunch of internal refactoring going on too: * No longer use operators to handle these directory and file fields, only makes things more complicated than they should be. * Handle autocomplete partial/full match deeper in the UI code * Directory field still does not keep focus, that's for another time to fix, you can already do pretty quick keyboard only navigation with the file field. Reviewed By: elubie Differential Revision: http://developer.blender.org/D29
2013-11-22 01:35:38 +01:00
int ui_searchbox_autocomplete(bContext *C, ARegion *ar, uiBut *but, char *str)
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
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;
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
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[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
data->items.autocpl = UI_autocomplete_begin(str, ui_but_string_get_max_length(but));
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
2.5 Two bugfixes, reported by Sebastian Skejo in IRC: - File operator poll wasn't secure, search for it crashed - Knife tool depends on having view3d context, fixed poll for it
2009-07-29 18:15:46 +00:00
but->search_func(C, but->search_arg, but->editstr, &data->items);
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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
match = UI_autocomplete_end(data->items.autocpl, str);
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.autocpl = NULL;
2.5 Two bugfixes, reported by Sebastian Skejo in IRC: - File operator poll wasn't secure, search for it crashed - Knife tool depends on having view3d context, fixed poll for it
2009-07-29 18:15:46 +00:00
}
File Browser: autocomplete keeps focus in the file field when entering a folder. There is a bunch of internal refactoring going on too: * No longer use operators to handle these directory and file fields, only makes things more complicated than they should be. * Handle autocomplete partial/full match deeper in the UI code * Directory field still does not keep focus, that's for another time to fix, you can already do pretty quick keyboard only navigation with the file field. Reviewed By: elubie Differential Revision: http://developer.blender.org/D29
2013-11-22 01:35:38 +01:00
return match;
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
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
static void ui_searchbox_region_draw_cb(const bContext *UNUSED(C), ARegion *ar)
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: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
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
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
/* pixel space */
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
wmOrtho2_region_ui(ar);
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
code cleanup: use bools, (float)sin/(float)cos -> sinf/cosf, more meaningful var names.
2013-04-04 04:22:38 +00:00
if (data->noback == false)
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_draw_search_back(NULL, NULL, &data->bbox); /* style not used yet */
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
/* draw text */
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 (data->items.totitem) {
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
rcti rect;
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
int a;
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
if (data->preview) {
/* draw items */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < data->items.totitem; a++) {
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
ui_searchbox_butrect(&rect, data, a);
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
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
/* widget itself */
UI cleanup: removing if, condition was already tested
2015-05-29 09:27:23 +01:00
ui_draw_preview_item(&data->fstyle, &rect, data->items.names[a], data->items.icons[a],
(a == data->active) ? UI_ACTIVE : 0);
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
}
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
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
/* indicate more */
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 (data->items.more) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_searchbox_butrect(&rect, data, data->items.maxitem - 1);
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
glEnable(GL_BLEND);
style cleanup: interface
2012-03-30 01:51:25 +00:00
UI_icon_draw(rect.xmax - 18, rect.ymin - 7, ICON_TRIA_DOWN);
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
glDisable(GL_BLEND);
}
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 (data->items.offset) {
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
ui_searchbox_butrect(&rect, data, 0);
glEnable(GL_BLEND);
style cleanup: interface
2012-03-30 01:51:25 +00:00
UI_icon_draw(rect.xmin, rect.ymax - 9, ICON_TRIA_UP);
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
glDisable(GL_BLEND);
}
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +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 {
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
/* draw items */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < data->items.totitem; a++) {
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
ui_searchbox_butrect(&rect, data, a);
/* widget itself */
fix [#36699] ASCII-character "|" blocks parenting don't split '|' for rna-property search buttons (but keep for operator search).
2013-09-11 04:56:35 +00:00
ui_draw_menu_item(&data->fstyle, &rect, data->items.names[a], data->items.icons[a],
(a == data->active) ? UI_ACTIVE : 0, data->use_sep);
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
}
/* indicate more */
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 (data->items.more) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_searchbox_butrect(&rect, data, data->items.maxitem - 1);
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
glEnable(GL_BLEND);
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
UI_icon_draw((BLI_rcti_size_x(&rect)) / 2, rect.ymin - 9, ICON_TRIA_DOWN);
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
glDisable(GL_BLEND);
}
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 (data->items.offset) {
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
ui_searchbox_butrect(&rect, data, 0);
glEnable(GL_BLEND);
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
UI_icon_draw((BLI_rcti_size_x(&rect)) / 2, rect.ymax - 7, ICON_TRIA_UP);
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
glDisable(GL_BLEND);
}
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
}
}
}
- UNUSED macro wasn't throwing an error with GCC if a var become used. - made interface, windowmanager, readfile build without unused warnings. - re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
2010-10-16 02:40:31 +00:00
static void ui_searchbox_region_free_cb(ARegion *ar)
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: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
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
int a;
/* free search data */
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
for (a = 0; a < data->items.maxitem; a++) {
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
MEM_freeN(data->items.names[a]);
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
}
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
MEM_freeN(data->items.names);
MEM_freeN(data->items.pointers);
2.5 Added support for icons in search menu. It already displays icons for saved materials etc. from old files. Have to add previewrenders for this still.
2009-06-24 16:44:54 +00:00
MEM_freeN(data->items.icons);
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
MEM_freeN(data);
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->regiondata = NULL;
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
}
ARegion *ui_searchbox_create(bContext *C, ARegion *butregion, uiBut *but)
{
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
wmWindow *win = CTX_wm_window(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
uiStyle *style = UI_style_get();
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
static ARegionType type;
ARegion *ar;
uiSearchboxData *data;
style cleanup: interface
2012-03-30 01:51:25 +00:00
float aspect = but->block->aspect;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rctf rect_fl;
rcti rect_i;
Remove redundant workaround for T41548 Reverts 7a026971dc3f93 which isn't needed anymore after b347f523cececdf
2015-08-14 22:16:04 +02:00
const int margin = UI_POPUP_MARGIN;
style cleanup: stop the style checker script from complaining about '!*ptr'
2012-12-15 02:48:25 +00:00
int winx /*, winy */, ofsx, ofsy;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int i;
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
/* create area 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
ar = ui_region_temp_add(CTX_wm_screen(C));
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
memset(&type, 0, sizeof(ARegionType));
style cleanup: interface
2012-03-30 01:51:25 +00:00
type.draw = ui_searchbox_region_draw_cb;
type.free = ui_searchbox_region_free_cb;
Fix #35880: popup menus like F6 redo did not use the right theme color for highlighted text, it should use the UI instead of 3D view color.
2013-06-26 12:24:36 +00:00
type.regionid = RGN_TYPE_TEMPORARY;
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->type = &type;
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
/* create searchbox data */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data = MEM_callocN(sizeof(uiSearchboxData), "uiSearchboxData");
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
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
/* set font, get bb */
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->fstyle = style->widget; /* copy struct */
data->fstyle.align = UI_STYLE_TEXT_CENTER;
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_fontscale(&data->fstyle.points, aspect);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(&data->fstyle);
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: interface
2012-03-30 01:51:25 +00:00
ar->regiondata = data;
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
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
/* special case, hardcoded feature, not draw backdrop when called from menus,
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
* assume for design that popup already added it */
Fix #30940: layout.prop_search() item not drawing correct inside menus.
2012-10-24 21:57:07 +00:00
if (but->block->flag & UI_BLOCK_SEARCH_MENU)
code cleanup: use bools, (float)sin/(float)cos -> sinf/cosf, more meaningful var names.
2013-04-04 04:22:38 +00:00
data->noback = true;
2.5 Search menu: - Made nicer drawing for popup version of search. It now uses entire backdrop like pulldowns. Search boxes for text buttons will use different style still; if we use this option all over it shouldn't look too intrusive. - Search menu allows scroll, to view all items. It doesn't cycle anymore. - Click outside search menu now cancels - If a match is in search button, it highlights it. This also allows ALT+CTRL+F - Enter to redo last op. - Search popup draws higher when no no space below. No order flipping!
2009-06-05 16:11:18 +00:00
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
if (but->a1 > 0 && but->a2 > 0) {
code cleanup: use bools, (float)sin/(float)cos -> sinf/cosf, more meaningful var names.
2013-04-04 04:22:38 +00:00
data->preview = true;
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
data->prv_rows = but->a1;
data->prv_cols = but->a2;
}
fix [#36699] ASCII-character "|" blocks parenting don't split '|' for rna-property search buttons (but keep for operator search).
2013-09-11 04:56:35 +00:00
/* only show key shortcuts when needed (not rna buttons) [#36699] */
if (but->rnaprop == NULL) {
data->use_sep = 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
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
/* compute position */
Fix #30940: layout.prop_search() item not drawing correct inside menus.
2012-10-24 21:57:07 +00:00
if (but->block->flag & UI_BLOCK_SEARCH_MENU) {
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
const int search_but_h = BLI_rctf_size_y(&but->rect) + 10;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* this case is search menu inside other menu */
/* we copy region size */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar->winrct = butregion->winrct;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* widget rect, in region coords */
Remove redundant workaround for T41548 Reverts 7a026971dc3f93 which isn't needed anymore after b347f523cececdf
2015-08-14 22:16:04 +02:00
data->bbox.xmin = margin;
data->bbox.xmax = BLI_rcti_size_x(&ar->winrct) - margin;
data->bbox.ymin = margin;
data->bbox.ymax = BLI_rcti_size_y(&ar->winrct) - margin;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
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
/* check if button is lower half */
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
if (but->rect.ymax < BLI_rctf_cent_y(&but->block->rect)) {
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
data->bbox.ymin += search_but_h;
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
}
else {
template ID previews: quick fix for buttons region overlapping the search button
2015-05-31 15:42:44 +02:00
data->bbox.ymax -= search_but_h;
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
}
}
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
const int searchbox_width = UI_searchbox_size_x();
UI todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50:39 +00:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rect_fl.xmin = but->rect.xmin - 5; /* align text with button */
rect_fl.xmax = but->rect.xmax + 5; /* symmetrical */
rect_fl.ymax = but->rect.ymin;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
rect_fl.ymin = rect_fl.ymax - UI_searchbox_size_y();
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
ofsx = (but->block->panel) ? but->block->panel->ofsx : 0;
ofsy = (but->block->panel) ? but->block->panel->ofsy : 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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rctf_translate(&rect_fl, ofsx, ofsy);
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
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* minimal width */
search box width's now scale with DPI setting. was checking on: [#33294] too small place for material names this helps in some cases but doesn't resolve issue with very long names.
2012-11-26 13:23:37 +00:00
if (BLI_rctf_size_x(&rect_fl) < searchbox_width) {
rect_fl.xmax = rect_fl.xmin + searchbox_width;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
}
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* copy to int, gets projected if possible too */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rcti_rctf_copy(&rect_i, &rect_fl);
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21: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 (butregion->v2d.cur.xmin != butregion->v2d.cur.xmax) {
View2d: API Cleanup for view<->region conversion View2D had some inconsistencies making it error prone in some cases. - Inconstant checking for NULL x/y args. Disallow NULL args for x/y destination pointers, instead add: - UI_view2d_region_to_view_x/y - UI_view2d_view_to_region_x/y - '_no_clip' suffix wasn't always used for non-clipping conversion, switch it around and use a '_clip' suffix for all funcs that clip. - UI_view2d_text_cache_add now clips before adding cache. - '_clip' funcs return a bool to quickly check if its in the view. - add conversion for rectangles, since this is a common task: - UI_view2d_view_to_region_rcti - UI_view2d_region_to_view_rctf
2014-04-21 16:47:16 +10:00
UI_view2d_view_to_region_rcti(&butregion->v2d, &rect_fl, &rect_i);
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
}
remove unneeded NULL check in ui_searchbox_create() which confuses static checkers since the values used later.
2011-12-18 22:42:43 +00:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rcti_translate(&rect_i, butregion->winrct.xmin, butregion->winrct.ymin);
remove unneeded NULL check in ui_searchbox_create() which confuses static checkers since the values used later.
2011-12-18 22:42:43 +00:00
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
winx = WM_window_pixels_x(win);
style cleanup: stop the style checker script from complaining about '!*ptr'
2012-12-15 02:48:25 +00:00
// winy = WM_window_pixels_y(win); /* UNUSED */
minor edits - add BLENDER_QUIT_FILE define. - use const for passing rcti's in widget drawing.
2012-12-13 02:40:49 +00:00
//wm_window_get_size(win, &winx, &winy);
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (rect_i.xmax > winx) {
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* super size */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (rect_i.xmax > winx + rect_i.xmin) {
rect_i.xmax = winx;
rect_i.xmin = 0;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
}
else {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rect_i.xmin -= rect_i.xmax - winx;
rect_i.xmax = winx;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +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
}
remove unneeded NULL check in ui_searchbox_create() which confuses static checkers since the values used later.
2011-12-18 22:42:43 +00:00
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
if (rect_i.ymin < 0) {
Fix #35802: searchbox menu not opening when opened from a popup near the bottom of the window.
2013-06-27 14:30:26 +00:00
int newy1 = but->rect.ymax + ofsy;
if (butregion->v2d.cur.xmin != butregion->v2d.cur.xmax)
View2d: API Cleanup for view<->region conversion View2D had some inconsistencies making it error prone in some cases. - Inconstant checking for NULL x/y args. Disallow NULL args for x/y destination pointers, instead add: - UI_view2d_region_to_view_x/y - UI_view2d_view_to_region_x/y - '_no_clip' suffix wasn't always used for non-clipping conversion, switch it around and use a '_clip' suffix for all funcs that clip. - UI_view2d_text_cache_add now clips before adding cache. - '_clip' funcs return a bool to quickly check if its in the view. - add conversion for rectangles, since this is a common task: - UI_view2d_view_to_region_rcti - UI_view2d_region_to_view_rctf
2014-04-21 16:47:16 +10:00
newy1 = UI_view2d_view_to_region_y(&butregion->v2d, newy1);
Fix #35802: searchbox menu not opening when opened from a popup near the bottom of the window.
2013-06-27 14:30:26 +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
newy1 += butregion->winrct.ymin;
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
rect_i.ymax = BLI_rcti_size_y(&rect_i) + newy1;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rect_i.ymin = newy1;
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
}
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
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* widget rect, in region coords */
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
data->bbox.xmin = margin;
data->bbox.xmax = BLI_rcti_size_x(&rect_i) + margin;
data->bbox.ymin = margin;
data->bbox.ymax = BLI_rcti_size_y(&rect_i) + margin;
2.5 Added search-browse to the Python ID template. Also added icon/button for 'Add new'. (Note, we need icon for it). Also fixed bug in search menu closing too quick on mouse-release, when mouse was close to bottom of menu button. And removed annoying warning if ID pointer was zero.
2009-06-11 17:21:27 +00:00
/* region bigger for shadow */
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
ar->winrct.xmin = rect_i.xmin - margin;
ar->winrct.xmax = rect_i.xmax + margin;
ar->winrct.ymin = rect_i.ymin - margin;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
ar->winrct.ymax = rect_i.ymax;
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
}
/* adds subwindow */
ED_region_init(C, ar);
/* notify change and redraw */
ED_region_tag_redraw(ar);
/* prepare search data */
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
if (data->preview) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.maxitem = data->prv_rows * data->prv_cols;
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
data->items.maxitem = SEARCH_ITEMS;
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
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.maxstrlen = but->hardmax;
data->items.totitem = 0;
data->items.names = MEM_callocN(data->items.maxitem * sizeof(void *), "search names");
data->items.pointers = MEM_callocN(data->items.maxitem * sizeof(void *), "search pointers");
data->items.icons = MEM_callocN(data->items.maxitem * sizeof(int), "search icons");
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
for (i = 0; i < data->items.maxitem; i++)
data->items.names[i] = MEM_callocN(but->hardmax + 1, "search pointers");
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 ar;
}
void ui_searchbox_free(bContext *C, ARegion *ar)
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_region_temp_remove(C, CTX_wm_screen(C), ar);
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
}
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
/* sets red alert if button holds a string it can't find */
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
/* XXX weak: search_func adds all partial matches... */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_search_refresh(uiBut *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
{
Commit r33378 adds a red alert to search buttons which have items which are not in the list. Disable this for pointer buttons since this was intended for vgroups & uvlayers. Pointer buttons often reference ID's which can be in the 1000+, lookups like this on each button draw is not useful since invalid pointers here will likely crash on scene evaluation.
2011-04-05 07:13:23 +00:00
uiSearchItems *items;
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
int x1;
Commit r33378 adds a red alert to search buttons which have items which are not in the list. Disable this for pointer buttons since this was intended for vgroups & uvlayers. Pointer buttons often reference ID's which can be in the 1000+, lookups like this on each button draw is not useful since invalid pointers here will likely crash on scene evaluation.
2011-04-05 07:13:23 +00:00
/* possibly very large lists (such as ID datablocks) only
* only validate string RNA buts (not pointers) */
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_STRING) {
Commit r33378 adds a red alert to search buttons which have items which are not in the list. Disable this for pointer buttons since this was intended for vgroups & uvlayers. Pointer buttons often reference ID's which can be in the 1000+, lookups like this on each button draw is not useful since invalid pointers here will likely crash on scene evaluation.
2011-04-05 07:13:23 +00:00
return;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
items = MEM_callocN(sizeof(uiSearchItems), "search items");
Commit r33378 adds a red alert to search buttons which have items which are not in the list. Disable this for pointer buttons since this was intended for vgroups & uvlayers. Pointer buttons often reference ID's which can be in the 1000+, lookups like this on each button draw is not useful since invalid pointers here will likely crash on scene evaluation.
2011-04-05 07:13:23 +00:00
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
/* setup search struct */
style cleanup: interface
2012-03-30 01:51:25 +00:00
items->maxitem = 10;
items->maxstrlen = 256;
items->names = MEM_callocN(items->maxitem * sizeof(void *), "search names");
for (x1 = 0; x1 < items->maxitem; x1++)
items->names[x1] = MEM_callocN(but->hardmax + 1, "search names");
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
but->search_func(but->block->evil_C, but->search_arg, but->drawstr, items);
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
/* only redalert when we are sure of it, this can miss cases when >10 matches */
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
if (items->totitem == 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_but_flag_enable(but, UI_BUT_REDALERT);
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (items->more == 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
if (UI_search_items_find_index(items, but->drawstr) == -1) {
UI_but_flag_enable(but, UI_BUT_REDALERT);
fix [#35178] Autoselect-in-list for Vertex Group selection doesn't work. disallow assigning values that don't exist into a text field with a search-box.
2013-05-02 04:59:52 +00: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
}
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +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
for (x1 = 0; x1 < items->maxitem; x1++) {
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
MEM_freeN(items->names[x1]);
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
}
Bugfix, irc report. UI name buttons with Search callback show red when item couldn't be found. The check was too simple though, since the searches also find partial matches. This caused KeyingSet browse to show red for "RotScale". Now 10 matches are stored, and each match is being checked. Still a bit weak for cases with more than 10 matches, but in that case it won't show red-alert.
2010-12-28 11:56:18 +00:00
MEM_freeN(items->names);
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
MEM_freeN(items);
}
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/************************* Creating Menu Blocks **********************/
/* position block relative to but, result is in window space */
static void ui_block_position(wmWindow *window, ARegion *butregion, uiBut *but, uiBlock *block)
{
uiBut *bt;
uiSafetyRct *saferct;
rctf butrct;
comment unused lines.
2011-08-15 03:41:31 +00:00
/*float aspect;*/ /*UNUSED*/
style cleanup: interface
2012-03-30 01:51:25 +00:00
int xsize, ysize, xof = 0, yof = 0, center;
short dir1 = 0, dir2 = 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
/* transform to window coordinates, using the source button region/block */
Code cleanup: UI use ui_block_to_window_rctf where possible
2014-05-02 09:31:48 +10:00
ui_block_to_window_rctf(butregion, but->block, &butrct, &but->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
UI: buttons that open menus now align to the menu rather than looking disconnected. Also fixed some cases where the menu was offset 1 or 2 pixels wrong, though not quite all of them, still off by 1 pixel sometimes. http://www.pasteall.org/pic/show.php?id=38478
2012-10-04 20:12:05 +00:00
/* widget_roundbox_set has this correction too, keep in sync */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_PULLDOWN) {
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_TOP)
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
butrct.ymax += U.pixelsize;
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_LEFT)
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
butrct.xmin -= U.pixelsize;
UI: buttons that open menus now align to the menu rather than looking disconnected. Also fixed some cases where the menu was offset 1 or 2 pixels wrong, though not quite all of them, still off by 1 pixel sometimes. http://www.pasteall.org/pic/show.php?id=38478
2012-10-04 20:12:05 +00: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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* calc block rect */
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 == 0.0f && block->rect.xmax == 0.0f) {
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->buttons.first) {
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
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
}
}
else {
/* we're nice and allow empty blocks too */
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->rect.ymin = 0;
block->rect.xmax = block->rect.ymax = 20;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00: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
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
/* aspect = (float)(BLI_rcti_size_x(&block->rect) + 4);*/ /*UNUSED*/
Code cleanup: UI use ui_block_to_window_rctf where possible
2014-05-02 09:31:48 +10:00
ui_block_to_window_rctf(butregion, but->block, &block->rect, &block->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
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 -= 2.0; block->rect.ymin -= 2.0;
//block->rect.xmax += 2.0; block->rect.ymax += 2.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
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
xsize = BLI_rctf_size_x(&block->rect) + 0.2f * UI_UNIT_X; /* 4 for shadow */
ysize = BLI_rctf_size_y(&block->rect) + 0.2f * UI_UNIT_Y;
style cleanup
2012-05-27 19:40:36 +00:00
/* aspect /= (float)xsize;*/ /*UNUSED*/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 access past the buffer size (paint / sculpt used some 2d vecs as 3d) - remove redundant NULL checks on old code where it would crash if the result was NULL later on. - add some missing NULL checks.
2011-09-16 06:47:01 +00:00
{
Cleanup: remove unused UI_SHIFT_FLIPPED (2.4x toolbox)
2014-11-09 17:16:46 +01:00
bool left = 0, right = 0, top = 0, down = 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
int winx, winy;
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
// int offscreen;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00: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
winx = WM_window_pixels_x(window);
winy = WM_window_pixels_y(window);
// wm_window_get_size(window, &winx, &winy);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (block->direction & UI_DIR_CENTER_Y) {
center = ysize / 2;
}
else {
center = 0;
}
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
/* check if there's space at all */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (butrct.xmin - xsize > 0.0f) left = 1;
if (butrct.xmax + xsize < winx) right = 1;
if (butrct.ymin - ysize + center > 0.0f) down = 1;
if (butrct.ymax + ysize - center < winy) top = 1;
if (top == 0 && down == 0) {
if (butrct.ymin - ysize < winy - butrct.ymax - ysize)
top = 1;
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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
down = 1;
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 Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
dir1 = (block->direction & UI_DIR_ALL);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* secundary directions */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir1 & (UI_DIR_UP | UI_DIR_DOWN)) {
if (dir1 & UI_DIR_LEFT) dir2 = UI_DIR_LEFT;
else if (dir1 & UI_DIR_RIGHT) dir2 = UI_DIR_RIGHT;
dir1 &= (UI_DIR_UP | UI_DIR_DOWN);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 ((dir2 == 0) && (dir1 == UI_DIR_LEFT || dir1 == UI_DIR_RIGHT)) dir2 = UI_DIR_DOWN;
if ((dir2 == 0) && (dir1 == UI_DIR_UP || dir1 == UI_DIR_DOWN)) dir2 = UI_DIR_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
spelling cleanup
2012-03-18 07:38:51 +00:00
/* no space at all? don't change */
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 (left || right) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir1 == UI_DIR_LEFT && left == 0) dir1 = UI_DIR_RIGHT;
if (dir1 == UI_DIR_RIGHT && right == 0) dir1 = UI_DIR_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
/* this is aligning, not append! */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir2 == UI_DIR_LEFT && right == 0) dir2 = UI_DIR_RIGHT;
if (dir2 == UI_DIR_RIGHT && left == 0) dir2 = UI_DIR_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
}
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 (down || top) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir1 == UI_DIR_UP && top == 0) dir1 = UI_DIR_DOWN;
if (dir1 == UI_DIR_DOWN && down == 0) dir1 = UI_DIR_UP;
Correct recent cleanup Removed call which was still needed
2015-05-15 11:29:34 +10:00
BLI_assert(dir2 != UI_DIR_UP);
Fix some issues found by Coverity Scan Some of them are just brain dead code, some are potential bugs.
2015-05-14 23:58:08 +02:00
// if (dir2 == UI_DIR_UP && top == 0) dir2 = UI_DIR_DOWN;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir2 == UI_DIR_DOWN && down == 0) dir2 = UI_DIR_UP;
style cleanup: interface
2012-03-30 01:51:25 +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 (dir1 == UI_DIR_LEFT) {
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
xof = butrct.xmin - block->rect.xmax;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir2 == UI_DIR_UP) yof = butrct.ymin - block->rect.ymin - center - MENU_PADDING;
else yof = butrct.ymax - block->rect.ymax + center + MENU_PADDING;
style cleanup: interface
2012-03-30 01:51:25 +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
else if (dir1 == UI_DIR_RIGHT) {
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
xof = butrct.xmax - block->rect.xmin;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (dir2 == UI_DIR_UP) yof = butrct.ymin - block->rect.ymin - center - MENU_PADDING;
else yof = butrct.ymax - block->rect.ymax + center + MENU_PADDING;
style cleanup: interface
2012-03-30 01:51:25 +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
else if (dir1 == UI_DIR_UP) {
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
yof = butrct.ymax - block->rect.ymin;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir2 == UI_DIR_RIGHT) xof = butrct.xmax - block->rect.xmax;
else xof = butrct.xmin - block->rect.xmin;
style cleanup
2012-08-19 10:41:27 +00:00
/* changed direction? */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if ((dir1 & block->direction) == 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_order_flip(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
else if (dir1 == UI_DIR_DOWN) {
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
yof = butrct.ymin - block->rect.ymax;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (dir2 == UI_DIR_RIGHT) xof = butrct.xmax - block->rect.xmax;
else xof = butrct.xmin - block->rect.xmin;
style cleanup
2012-08-19 10:41:27 +00:00
/* changed direction? */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if ((dir1 & block->direction) == 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_order_flip(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
}
}
/* and now we handle the exception; no space below or to top */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (top == 0 && down == 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
if (dir1 == UI_DIR_LEFT || dir1 == UI_DIR_RIGHT) {
style cleanup
2012-08-19 10:41:27 +00:00
/* align with bottom of screen */
style cleanup
2012-10-26 04:14:10 +00:00
// yof = ysize; (not with menu scrolls)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
/* or no space left or right */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (left == 0 && right == 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
if (dir1 == UI_DIR_UP || dir1 == UI_DIR_DOWN) {
style cleanup
2012-08-19 10:41:27 +00:00
/* align with left size of screen */
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
xof = -block->rect.xmin + 5;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
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
#if 0
bugfix [#23311] Half a colour picker appears all popups which are positioned based on an existing button are now clamped to window bounds.
2010-10-06 14:17:28 +00:00
/* clamp to window bounds, could be made into an option if its ever annoying */
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 ( (offscreen = (block->rect.ymin + yof)) < 0) yof -= offscreen; /* bottom */
else if ((offscreen = (block->rect.ymax + yof) - winy) > 0) yof -= offscreen; /* top */
if ( (offscreen = (block->rect.xmin + xof)) < 0) xof -= offscreen; /* left */
else if ((offscreen = (block->rect.xmax + xof) - winx) > 0) xof -= offscreen; /* right */
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
#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
}
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
/* apply offset, buttons in window coords */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
for (bt = block->buttons.first; bt; bt = bt->next) {
Code cleanup: UI use ui_block_to_window_rctf where possible
2014-05-02 09:31:48 +10:00
ui_block_to_window_rctf(butregion, but->block, &bt->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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
BLI_rctf_translate(&bt->rect, xof, yof);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 recalculates drawstring size in pixels */
ui_but_update(bt);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
BLI_rctf_translate(&block->rect, xof, yof);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 calculus */
code cleanup: remove more invalid/paranoid NULL checks
2012-09-15 07:42:30 +00:00
{
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
const float midx = BLI_rctf_cent_x(&butrct);
const float midy = BLI_rctf_cent_y(&butrct);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* when you are outside parent button, safety there should be smaller */
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* parent button to left */
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 (midx < block->rect.xmin) block->safety.xmin = block->rect.xmin - 3;
else block->safety.xmin = block->rect.xmin - 40;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* parent button to right */
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 (midx > block->rect.xmax) block->safety.xmax = block->rect.xmax + 3;
else block->safety.xmax = block->rect.xmax + 40;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* parent button on bottom */
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 (midy < block->rect.ymin) block->safety.ymin = block->rect.ymin - 3;
else block->safety.ymin = block->rect.ymin - 40;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* parent button on top */
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 (midy > block->rect.ymax) block->safety.ymax = block->rect.ymax + 3;
else block->safety.ymax = block->rect.ymax + 40;
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* exception for switched pulldowns... */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir1 && (dir1 & block->direction) == 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
if (dir2 == UI_DIR_RIGHT) block->safety.xmax = block->rect.xmax + 3;
if (dir2 == UI_DIR_LEFT) block->safety.xmin = block->rect.xmin - 3;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->direction = dir1;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
/* keep a list of these, needed for pulldown menus */
style cleanup: interface
2012-03-30 01:51:25 +00:00
saferct = MEM_callocN(sizeof(uiSafetyRct), "uiSafetyRct");
saferct->parent = butrct;
saferct->safety = block->safety;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
BLI_freelistN(&block->saferct);
code cleanup: remove more invalid/paranoid NULL checks
2012-09-15 07:42:30 +00:00
BLI_duplicatelist(&block->saferct, &but->block->saferct);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_addhead(&block->saferct, saferct);
}
static void ui_block_region_draw(const bContext *C, ARegion *ar)
{
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
if (ar->do_draw & RGN_DRAW_REFRESH_UI) {
uiBlock *block_next;
ar->do_draw &= ~RGN_DRAW_REFRESH_UI;
for (block = ar->uiblocks.first; block; block = block_next) {
block_next = block->next;
ui_popup_block_refresh((bContext *)C, block->handle, NULL, NULL);
}
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (block = ar->uiblocks.first; block; block = block->next)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_draw(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
}
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
static void ui_popup_block_clip(wmWindow *window, uiBlock *block)
{
Bug fix #33633 (and irc report) The function ui_popup_block_clip() didn't correct the buttons if a clip happened, causing the items to draw outside.
2012-12-26 13:57:07 +00:00
uiBut *bt;
Bug fix #35307 Popup menus in nodes, with nodes outside window boundary, were clipped very badly, even causing it to fill entire window. Now the clip code nicely translates the menu horizontally to be in view.
2013-05-11 15:29:57 +00:00
float xofs = 0.0f;
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
int width = UI_SCREEN_MARGIN;
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
int winx, winy;
fix [#32938] The Splash Screen doesn't show up correctly ..... applying window clipping to the splash on startup gave strange/annoying problems.
2012-10-25 02:57:55 +00:00
if (block->flag & UI_BLOCK_NO_WIN_CLIP) {
return;
}
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
winx = WM_window_pixels_x(window);
winy = WM_window_pixels_y(window);
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
Bug fix #35307 Popup menus in nodes, with nodes outside window boundary, were clipped very badly, even causing it to fill entire window. Now the clip code nicely translates the menu horizontally to be in view.
2013-05-11 15:29:57 +00:00
/* shift menus to right if outside of view */
if (block->rect.xmin < width) {
xofs = (width - block->rect.xmin);
block->rect.xmin += xofs;
block->rect.xmax += xofs;
}
/* or shift to left if outside of view */
if (block->rect.xmax > winx - width) {
xofs = winx - width - block->rect.xmax;
block->rect.xmin += xofs;
block->rect.xmax += xofs;
}
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 todo: - Recoded soft shadow drawing for menus, giving better predictable results (and round off nicer on top side, was looking bad still) - Brought it under DPI control - Added Theme setting to control size and strength for it. Max size 24 pix: http://wiki.blender.org/index.php/File:MenuShadow.png
2012-12-20 16:50:39 +00:00
if (block->rect.ymin < width)
block->rect.ymin = width;
UI: expose UI_POPUP_MENU_TOP for use elsewhere.
2015-10-17 00:21:35 +11:00
if (block->rect.ymax > winy - UI_POPUP_MENU_TOP)
block->rect.ymax = winy - UI_POPUP_MENU_TOP;
Bug fix #33633 (and irc report) The function ui_popup_block_clip() didn't correct the buttons if a clip happened, causing the items to draw outside.
2012-12-26 13:57:07 +00:00
/* ensure menu items draw inside left/right boundary */
for (bt = block->buttons.first; bt; bt = bt->next) {
Bug fix #35307 Popup menus in nodes, with nodes outside window boundary, were clipped very badly, even causing it to fill entire window. Now the clip code nicely translates the menu horizontally to be in view.
2013-05-11 15:29:57 +00:00
bt->rect.xmin += xofs;
bt->rect.xmax += xofs;
Bug fix #33633 (and irc report) The function ui_popup_block_clip() didn't correct the buttons if a clip happened, causing the items to draw outside.
2012-12-26 13:57:07 +00:00
}
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
}
void ui_popup_block_scrolltest(uiBlock *block)
{
uiBut *bt;
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->flag &= ~(UI_BLOCK_CLIPBOTTOM | UI_BLOCK_CLIPTOP);
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (bt = block->buttons.first; bt; bt = bt->next)
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
bt->flag &= ~UI_SCROLLED;
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (block->buttons.first == block->buttons.last)
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
return;
UI: fix for menu scrolling when window is too small. It was not working well with arbitrary button layouts like multi column menus, because it was making assumptions about position of previous/next buttons which doesn't work in general.
2012-10-31 11:31:30 +00:00
/* mark buttons that are outside boundary */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (bt = block->buttons.first; bt; bt = bt->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 (bt->rect.ymin < block->rect.ymin) {
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
bt->flag |= UI_SCROLLED;
block->flag |= UI_BLOCK_CLIPBOTTOM;
}
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 (bt->rect.ymax > block->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
bt->flag |= UI_SCROLLED;
block->flag |= UI_BLOCK_CLIPTOP;
UI: fix for menu scrolling when window is too small. It was not working well with arbitrary button layouts like multi column menus, because it was making assumptions about position of previous/next buttons which doesn't work in general.
2012-10-31 11:31:30 +00:00
}
}
/* mark buttons overlapping arrows, if we have them */
for (bt = block->buttons.first; bt; bt = bt->next) {
style cleanup and correct own invalid comment.
2012-10-31 11:45:41 +00:00
if (block->flag & UI_BLOCK_CLIPBOTTOM) {
Fix #31482: menu with scrollers when window is too small, didn't auto scroll when using the arrow keys or mouse wheel to activate the next item.
2012-10-31 12:56:04 +00:00
if (bt->rect.ymin < block->rect.ymin + UI_MENU_SCROLL_ARROW)
UI: fix for menu scrolling when window is too small. It was not working well with arbitrary button layouts like multi column menus, because it was making assumptions about position of previous/next buttons which doesn't work in general.
2012-10-31 11:31:30 +00:00
bt->flag |= UI_SCROLLED;
}
style cleanup and correct own invalid comment.
2012-10-31 11:45:41 +00:00
if (block->flag & UI_BLOCK_CLIPTOP) {
Fix #31482: menu with scrollers when window is too small, didn't auto scroll when using the arrow keys or mouse wheel to activate the next item.
2012-10-31 12:56:04 +00:00
if (bt->rect.ymax > block->rect.ymax - UI_MENU_SCROLL_ARROW)
UI: fix for menu scrolling when window is too small. It was not working well with arbitrary button layouts like multi column menus, because it was making assumptions about position of previous/next buttons which doesn't work in general.
2012-10-31 11:31:30 +00:00
bt->flag |= 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: 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
static void ui_popup_block_remove(bContext *C, uiPopupBlockHandle *handle)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_region_temp_remove(C, CTX_wm_screen(C), handle->region);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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 (handle->scrolltimer)
WM_event_remove_timer(CTX_wm_manager(C), CTX_wm_window(C), handle->scrolltimer);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/**
Cleanup: style
2015-06-16 10:18:45 +10:00
* Called for creating new popups and refreshing existing ones.
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
*/
uiBlock *ui_popup_block_refresh(
bContext *C, uiPopupBlockHandle *handle,
ARegion *butregion, uiBut *but)
{
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
const int margin = UI_POPUP_MARGIN;
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);
ARegion *ar = handle->region;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
uiBlockCreateFunc create_func = handle->popup_create_vars.create_func;
uiBlockHandleCreateFunc handle_create_func = handle->popup_create_vars.handle_create_func;
void *arg = handle->popup_create_vars.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: 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
uiBlock *block_old = ar->uiblocks.first;
uiBlock *block;
#ifdef DEBUG
wmEvent *event_back = window->eventstate;
#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
/* create ui block */
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 (create_func)
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 = create_func(C, ar, arg);
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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
block = handle_create_func(C, handle, arg);
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
/* callbacks _must_ leave this for us, otherwise we can't call UI_block_update_from_old */
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
BLI_assert(!block->endblock);
/* ensure we don't use mouse coords here! */
#ifdef DEBUG
window->eventstate = NULL;
#endif
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) {
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
memcpy(block->handle, handle, sizeof(uiPopupBlockHandle));
MEM_freeN(handle);
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = block->handle;
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
}
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->handle = handle;
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
ar->regiondata = handle;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* set UI_BLOCK_NUMSELECT before UI_block_end() so we get alphanumeric keys assigned */
Revert "Revert "Disable key accelerators for splash screen"" This reverts commit 7f3dcbe17feccb99abbdbc3aea83189696d97391. Please check with authors first, this bug was already fixed since RC1.
2015-06-15 10:59:49 +10:00
if (but == NULL) {
block->flag |= UI_BLOCK_POPUP;
make alphanumeric key shortcuts work for submenu's so you can chain keys together to select items in a menu. eg: 'Ctrl+V, E, S' for - Vertex, Separate, Selection
2012-09-10 06:44:25 +00:00
}
block->flag |= UI_BLOCK_LOOP;
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
/* defer this until blocks are translated (below) */
block->oldblock = 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
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_ex(C, block, handle->popup_create_vars.event_xy);
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
/* if this is being created from a button */
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) {
Fix #28011: Dropdown lists to add Brick elements in Game Logic view miss letters if zoomed small Now fonts in popup lists will also be scaled together with panel from which they're displaying.
2012-01-31 15:59:52 +00:00
block->aspect = but->block->aspect;
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
ui_block_position(window, butregion, but, block);
UI: buttons that open menus now align to the menu rather than looking disconnected. Also fixed some cases where the menu was offset 1 or 2 pixels wrong, though not quite all of them, still off by 1 pixel sometimes. http://www.pasteall.org/pic/show.php?id=38478
2012-10-04 20:12:05 +00:00
handle->direction = block->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
}
else {
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
uiSafetyRct *saferct;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* keep a list of these, needed for pulldown menus */
style cleanup: interface
2012-03-30 01:51:25 +00:00
saferct = MEM_callocN(sizeof(uiSafetyRct), "uiSafetyRct");
saferct->safety = block->safety;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
BLI_addhead(&block->saferct, saferct);
}
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) {
int win_width = UI_SCREEN_MARGIN;
int winx, winy;
int x_offset = 0, y_offset = 0;
winx = WM_window_pixels_x(window);
winy = WM_window_pixels_y(window);
copy_v2_v2(block->pie_data.pie_center_init, block->pie_data.pie_center_spawned);
/* only try translation if area is large enough */
if (BLI_rctf_size_x(&block->rect) < winx - (2.0f * win_width)) {
if (block->rect.xmin < win_width ) x_offset += win_width - block->rect.xmin;
if (block->rect.xmax > winx - win_width) x_offset += winx - win_width - block->rect.xmax;
}
if (BLI_rctf_size_y(&block->rect) < winy - (2.0f * win_width)) {
if (block->rect.ymin < win_width ) y_offset += win_width - block->rect.ymin;
if (block->rect.ymax > winy - win_width) y_offset += winy - win_width - block->rect.ymax;
}
/* if we are offsetting set up initial data for timeout functionality */
if ((x_offset != 0) || (y_offset != 0)) {
block->pie_data.pie_center_spawned[0] += x_offset;
block->pie_data.pie_center_spawned[1] += y_offset;
ui_block_translate(block, x_offset, y_offset);
if (U.pie_initial_timeout > 0)
block->pie_data.flags |= UI_PIE_INITIAL_DIRECTION;
}
ar->winrct.xmin = 0;
ar->winrct.xmax = winx;
ar->winrct.ymin = 0;
ar->winrct.ymax = winy;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_calc_pie_segment(block, block->pie_data.pie_center_init);
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
/* lastly set the buttons at the center of the pie menu, ready for animation */
if (U.pie_animation_timeout > 0) {
Cleanup: shadowing (interface)
2015-11-23 10:01:54 +11:00
for (uiBut *but_iter = block->buttons.first; but_iter; but_iter = but_iter->next) {
if (but_iter->pie_dir != UI_RADIAL_NONE) {
BLI_rctf_recenter(&but_iter->rect, UNPACK2(block->pie_data.pie_center_spawned));
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 {
/* clip block with window boundary */
ui_popup_block_clip(window, block);
/* the block and buttons were positioned in window space as in 2.4x, now
* these menu blocks are regions so we bring it back to region space.
* additionally we add some padding for the menu shadow or rounded menus */
Fix T42221: 'Shadow Width' influences tooltip size Positioning of popups was using shadow width for placement, could give some quite odd results.
2014-11-10 13:58:03 +01:00
ar->winrct.xmin = block->rect.xmin - margin;
ar->winrct.xmax = block->rect.xmax + margin;
ar->winrct.ymin = block->rect.ymin - margin;
UI: expose UI_POPUP_MENU_TOP for use elsewhere.
2015-10-17 00:21:35 +11:00
ar->winrct.ymax = block->rect.ymax + UI_POPUP_MENU_TOP;
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
ui_block_translate(block, -ar->winrct.xmin, -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
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_old) {
block->oldblock = block_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_block_update_from_old(C, block);
UI_blocklist_free_inactive(C, &ar->uiblocks);
UI: Add support for popups to refresh their layput (D578) This is needed for popups to chance state once activated, currently it makes use of operators `check` callback, after values are modified, as the file selector does already.
2014-06-15 01:40:15 +10:00
}
UI: getting popup menus to work again, just the internal interface and event handling code still, how it integrates with operators and handlers is not worked out yet. For testing, Ctrl+Q quit now shows a confirmation popup using the following call: okee_operator(C, "WM_OT_exit_blender", "Quit Blender");
2008-12-15 19:19:39 +00:00
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
/* checks which buttons are visible, sets flags to prevent draw (do after region init) */
ui_popup_block_scrolltest(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
/* adds subwindow */
ED_region_init(C, ar);
UI: getting popup menus to work again, just the internal interface and event handling code still, how it integrates with operators and handlers is not worked out yet. For testing, Ctrl+Q quit now shows a confirmation popup using the following call: okee_operator(C, "WM_OT_exit_blender", "Quit Blender");
2008-12-15 19:19:39 +00:00
/* get winmat now that we actually have the subwindow */
2.5 All of the view3d drawing code is now 'Context' free. The idea is: - ED_region_do_draw() sets and freezes drawing context - regiontype draw() callback then can pass on other relevant context stuff as function args. Also cleaned up the WM opengl wrappers, to mimic opengl state; no reason to give window pointer anymore.
2008-12-19 14:14:43 +00:00
wmSubWindowSet(window, ar->swinid);
2.5 Next part of UI drawing migration coding. Now all calls go via the new wrapper; apart from some special types (Colorband, HSV picking, Curve, Normal) they draw OK. Also added new menu system, nicer shadow, and using same AA code. Used dark theme suggestion from William btw. Don't get afraid, it'll all be tweakable. :) Next steps: - move over all special button types - make external calls for AA draw (nodes for example) - remove old draw code - make new colors save in theme I also have to check on how to treat icons in buttons; this is a bit cumbersome in cases. Then the layout system comes back on agenda, will go over this with Brecht tomorrow. So; all WIP, be patient!
2009-04-03 16:26:03 +00:00
Code cleanup: avoid redundant lookups for subwindows
2014-04-02 17:33:20 +11:00
wm_subwindow_matrix_get(window, ar->swinid, block->winmat);
2.5 Cleanup in area/region management - more intelligence in area management for adding handlers and setting data correct. Space/Region type callbacks only have to do own things. - added option for adding default handlers to areas/regions. (flag in type definition) - ensured that region-types store the minsizes for regions. - added boundbox check for handlers; note that it accepts pointer to boundbox, because handlers don't get reset on area-resizing or view changes. Example: view2d handlers use mask rect. - handlers get now added on correct context levels (example frame change also worked in header) - removed ->refresh() callback. Context refreshing is Listener. - the ->init() is being called on all WM level actions, also after a file read, moving areas, re-opening areas etc. - fixed bug: crash on exit was caused by cleaning up Screen too late. - UI_view2d_size_update() removed from draw callback, is init() - regions now store (winx, winy) subwindow size.
2008-12-10 13:56:54 +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
/* notify change and redraw */
2.5 Work on getting notifiers in shape. - Most important: local (to own region or area) redraw notifiers have been depricated. This is not a good or correct notifier anyway. Notifiers should be signals to other areas. - Instead use these 2 functions: ED_area_tag_redraw(area); ED_region_tag_redraw(region); It seems to me good convention to keep the area/region redraw tag itself protected everywhere, for future improvements. - Also added a basic WM function that checks overlapping regions, and flushes redraws to underlying regions. This makes menus and buttons allow to only send local region redraws. (Brought back two "swapbuffer indicators" to test this. - Todo: area 'action zone' redraws, and fixing other notifiers... sending data pointers in a notifier seems to be bad idea.
2008-12-16 12:28:00 +00:00
ED_region_tag_redraw(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
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
ED_region_update_rect(C, ar);
#ifdef DEBUG
window->eventstate = event_back;
#endif
return block;
}
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
uiPopupBlockHandle *ui_popup_block_create(
bContext *C, ARegion *butregion, uiBut *but,
uiBlockCreateFunc create_func, uiBlockHandleCreateFunc handle_create_func,
void *arg)
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);
static ARegionType type;
ARegion *ar;
uiBlock *block;
uiPopupBlockHandle *handle;
/* create handle */
handle = MEM_callocN(sizeof(uiPopupBlockHandle), "uiPopupBlockHandle");
/* store context for operator */
handle->ctx_area = CTX_wm_area(C);
handle->ctx_region = CTX_wm_region(C);
/* store vars to refresh popup (RGN_DRAW_REFRESH_UI) */
handle->popup_create_vars.create_func = create_func;
handle->popup_create_vars.handle_create_func = handle_create_func;
handle->popup_create_vars.arg = arg;
handle->popup_create_vars.butregion = but ? butregion : NULL;
copy_v2_v2_int(handle->popup_create_vars.event_xy, &window->eventstate->x);
/* create area 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
ar = ui_region_temp_add(CTX_wm_screen(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
handle->region = ar;
memset(&type, 0, sizeof(ARegionType));
type.draw = ui_block_region_draw;
type.regionid = RGN_TYPE_TEMPORARY;
ar->type = &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
UI_region_handlers_add(&ar->handlers);
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 = ui_popup_block_refresh(C, handle, butregion, but);
handle = block->handle;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 handle;
}
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
void ui_popup_block_free(bContext *C, uiPopupBlockHandle *handle)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
ui_popup_block_remove(C, handle);
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(handle);
}
/***************************** Menu Button ***************************/
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
#if 0
for bug [#27358] Transform bug when transform > 500 mouse coords would with cont. grab would wrap at short. use mouse coords as int rather then short. this problem still happens on linux because of XTranslateCoordinates
2011-05-12 16:47:36 +00:00
static void ui_warp_pointer(int x, int y)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
/* XXX 2.50 which function to use for this? */
style cleanup - spelling.
2012-03-08 04:12:11 +00:00
/* OSX has very poor mouse-warp support, it sends events;
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
* this causes a menu being pressed immediately ... */
style cleanup - spelling.
2012-03-08 04:12:11 +00:00
# ifndef __APPLE__
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
warp_pointer(x, y);
style cleanup - spelling.
2012-03-08 04:12:11 +00: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
}
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
#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
/********************* Color Button ****************/
/* for picker, while editing hsv */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_hsv_set(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
{
float col[3];
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
ColorPicker *cpicker = but->custom_data;
float *hsv = cpicker->color_data;
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
ui_color_picker_to_rgb_v(hsv, col);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_v3_set(but, col);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
/* Updates all buttons who share the same color picker as the one passed
* also used by small picker, be careful with name checks below... */
static void ui_update_color_picker_buts_rgb(uiBlock *block, ColorPicker *cpicker, const float rgb[3], bool is_display_space)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
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
float *hsv = cpicker->color_data;
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
struct ColorManagedDisplay *display = NULL;
Avoid reset the H and S value in the color picker when V is equal to zero! Small change to keep the value of H and S when V come to zero, take care that only work if you keep the color picker open. When the color picker is closed, the H and S value are reset to zero this is because the color picker is used in a lot of different place and this value need to be reset. (BTW reset to zero only when V is equal to zero!)
2010-06-02 16:02:28 +00:00
/* this is to keep the H and S value when V is equal to zero
* and we are working in HSV mode, of course!
*/
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
if (is_display_space) {
ui_rgb_to_color_picker_compat_v(rgb, hsv);
}
else {
/* we need to convert to display space to use hsv, because hsv is stored in display space */
float rgb_display[3];
copy_v3_v3(rgb_display, rgb);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_display_space_v3(block, rgb_display);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
ui_rgb_to_color_picker_compat_v(rgb_display, hsv);
}
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
if (block->color_profile)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
display = ui_block_cm_display_get(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: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* this updates button strings, is hackish... but button pointers are on stack of caller function */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (bt = block->buttons.first; bt; bt = bt->next) {
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
if (bt->custom_data != cpicker)
continue;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
if (bt->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
ui_but_v3_set(bt, rgb);
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
}
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
else if (STREQ(bt->str, "Hex: ")) {
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
float rgb_gamma[3];
Code cleanup: quiet warnings & style
2014-04-13 11:26:31 +10:00
unsigned char rgb_gamma_uchar[3];
Bugfix for [#21582] Adjusting material color (color picker) crashes This fixes only the crash, which was due to buffer overrun for col Hex char buffer. It doesn't actually fix the real issue of overflowing the color values up to infinity.
2010-03-30 10:13:55 +00:00
double intpart;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
char col[16];
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
/* Hex code is assumed to be in sRGB space (coming from other applications, web, etc) */
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
copy_v3_v3(rgb_gamma, rgb);
if (display) {
/* make a display version, for Hex code */
IMB_colormanagement_scene_linear_to_display_v3(rgb_gamma, display);
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
}
Bugfix for [#21582] Adjusting material color (color picker) crashes This fixes only the crash, which was due to buffer overrun for col Hex char buffer. It doesn't actually fix the real issue of overflowing the color values up to infinity.
2010-03-30 10:13:55 +00:00
if (rgb_gamma[0] > 1.0f) rgb_gamma[0] = modf(rgb_gamma[0], &intpart);
if (rgb_gamma[1] > 1.0f) rgb_gamma[1] = modf(rgb_gamma[1], &intpart);
if (rgb_gamma[2] > 1.0f) rgb_gamma[2] = modf(rgb_gamma[2], &intpart);
Code cleanup: quiet warnings & style
2014-04-13 11:26:31 +10:00
rgb_float_to_uchar(rgb_gamma_uchar, rgb_gamma);
Macros: replace UNPACK#OP -> UNPACK#_EX, allow suffix
2014-08-05 08:04:57 +10:00
BLI_snprintf(col, sizeof(col), "%02X%02X%02X", UNPACK3_EX((unsigned int), rgb_gamma_uchar, ));
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +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
strcpy(bt->poin, col);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (bt->str[1] == ' ') {
if (bt->str[0] == 'R') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, rgb[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
else if (bt->str[0] == 'G') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, rgb[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
else if (bt->str[0] == 'B') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, rgb[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
else if (bt->str[0] == '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
ui_but_value_set(bt, hsv[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
else if (bt->str[0] == 'S') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, hsv[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
else if (bt->str[0] == 'V') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, hsv[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
}
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
else if (bt->str[0] == 'L') {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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(bt, hsv[2]);
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
2.5: * Fix missing update when browsing to different text. * Fix wrong spacing in font size 15 drawing in the text editor. * Fix numbers not updating in color picker buttons.
2009-07-10 18:10:40 +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(bt);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_colorpicker_rna_cb(bContext *UNUSED(C), void *bt1, void *UNUSED(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
uiBut *but = (uiBut *)bt1;
uiPopupBlockHandle *popup = but->block->handle;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
PropertyRNA *prop = but->rnaprop;
PointerRNA ptr = but->rnapoin;
Color picker crash fix. Color arrays in RNA are 4 floats but handlers used 3 floats. Overflow galore.
2010-01-09 19:00:41 +00:00
float rgb[4];
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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/Py API change how data is added. eg. bpy.data.add_mesh(name) --> bpy.data.meshes.new(name) bpy.data.remove_lamp(lamp) --> bpy.data.lamps.remove(lamp) image and texture stil use add_* funcs
2010-01-09 23:44:01 +00:00
if (prop) {
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
RNA_property_float_get_array(&ptr, prop, rgb);
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
ui_update_color_picker_buts_rgb(but->block, but->custom_data, rgb, (RNA_property_subtype(prop) == PROP_COLOR_GAMMA));
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (popup)
style cleanup: interface
2012-03-30 01:51:25 +00:00
popup->menuretval = UI_RETURN_UPDATE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_color_wheel_rna_cb(bContext *UNUSED(C), void *bt1, void *UNUSED(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
uiBut *but = (uiBut *)bt1;
uiPopupBlockHandle *popup = but->block->handle;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
float rgb[3];
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
ColorPicker *cpicker = but->custom_data;
float *hsv = cpicker->color_data;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 use_display_colorspace = ui_but_is_colorpicker_display_space(but);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
ui_color_picker_to_rgb_v(hsv, rgb);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
/* hsv is saved in display space so convert back */
if (use_display_colorspace) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_scene_linear_v3(but->block, rgb);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
}
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
ui_update_color_picker_buts_rgb(but->block, cpicker, rgb, !use_display_colorspace);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (popup)
style cleanup: interface
2012-03-30 01:51:25 +00:00
popup->menuretval = UI_RETURN_UPDATE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_colorpicker_hex_rna_cb(bContext *UNUSED(C), void *bt1, void *hexcl)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
uiBut *but = (uiBut *)bt1;
uiPopupBlockHandle *popup = but->block->handle;
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
ColorPicker *cpicker = but->custom_data;
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *hexcol = (char *)hexcl;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
float rgb[3];
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
hex_to_rgb(hexcol, rgb, rgb + 1, rgb + 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
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
/* Hex code is assumed to be in sRGB space (coming from other applications, web, etc) */
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
if (but->block->color_profile) {
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
/* so we need to linearise it for Blender */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_scene_linear_v3(but->block, rgb);
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
}
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
ui_update_color_picker_buts_rgb(but->block, cpicker, rgb, 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
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 (popup)
style cleanup: interface
2012-03-30 01:51:25 +00:00
popup->menuretval = UI_RETURN_UPDATE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_popup_close_cb(bContext *UNUSED(C), void *bt1, void *UNUSED(arg))
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiBut *but = (uiBut *)bt1;
uiPopupBlockHandle *popup = but->block->handle;
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22: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 (popup)
style cleanup: interface
2012-03-30 01:51:25 +00:00
popup->menuretval = UI_RETURN_OK;
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22: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_colorpicker_hide_reveal(uiBlock *block, short colormode)
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
{
uiBut *bt;
/* tag buttons */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (bt = block->buttons.first; bt; bt = bt->next) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 ((bt->func == ui_colorpicker_rna_cb) && bt->type == UI_BTYPE_NUM_SLIDER && bt->rnaindex != 3) {
fix for error in own recent commit: do not hide alpha in HSV and Hex modes
2012-09-08 19:40:34 +00:00
/* RGB sliders (color circle and alpha are always shown) */
Use function pointers instead of hard-coded english button names in color picker block. This solves the problem with es/ru translations of color picker block reported by Gabriel Gazzán in Bf-translations-dev.
2012-09-02 13:36:33 +00:00
if (colormode == 0) bt->flag &= ~UI_HIDDEN;
else bt->flag |= UI_HIDDEN;
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +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
else if (bt->func == ui_color_wheel_rna_cb) {
Use function pointers instead of hard-coded english button names in color picker block. This solves the problem with es/ru translations of color picker block reported by Gabriel Gazzán in Bf-translations-dev.
2012-09-02 13:36:33 +00:00
/* HSV sliders */
if (colormode == 1) bt->flag &= ~UI_HIDDEN;
else bt->flag |= UI_HIDDEN;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 (bt->func == ui_colorpicker_hex_rna_cb || bt->type == UI_BTYPE_LABEL) {
Use function pointers instead of hard-coded english button names in color picker block. This solves the problem with es/ru translations of color picker block reported by Gabriel Gazzán in Bf-translations-dev.
2012-09-02 13:36:33 +00:00
/* hex input or gamma correction status label */
if (colormode == 2) bt->flag &= ~UI_HIDDEN;
else bt->flag |= UI_HIDDEN;
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +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_colorpicker_create_mode_cb(bContext *UNUSED(C), void *bt1, void *UNUSED(arg))
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiBut *bt = bt1;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
short colormode = ui_but_value_get(bt);
ui_colorpicker_hide_reveal(bt->block, colormode);
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00: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
#define PICKER_H (7.5f * U.widget_unit)
#define PICKER_W (7.5f * U.widget_unit)
#define PICKER_SPACE (0.3f * U.widget_unit)
#define PICKER_BAR (0.7f * U.widget_unit)
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
#define PICKER_TOTAL_W (PICKER_W + PICKER_SPACE + PICKER_BAR)
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +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_colorpicker_circle(uiBlock *block, PointerRNA *ptr, PropertyRNA *prop, ColorPicker *cpicker)
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
{
uiBut *bt;
/* HS circle */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButR_prop(block, UI_BTYPE_HSVCIRCLE, 0, "", 0, 0, PICKER_H, PICKER_W, ptr, prop, -1, 0.0, 0.0, 0.0, 0, TIP_("Color"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
/* value */
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
if (U.color_picker_type == USER_CP_CIRCLE_HSL) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButR_prop(block, UI_BTYPE_HSVCUBE, 0, "", PICKER_W + PICKER_SPACE, 0, PICKER_BAR, PICKER_H, ptr, prop, -1, 0.0, 0.0, UI_GRAD_L_ALT, 0, "Lightness");
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
}
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
bt = uiDefButR_prop(block, UI_BTYPE_HSVCUBE, 0, "", PICKER_W + PICKER_SPACE, 0, PICKER_BAR, PICKER_H, ptr, prop, -1, 0.0, 0.0, UI_GRAD_V_ALT, 0, TIP_("Value"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
}
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
bt->custom_data = cpicker;
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +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_colorpicker_square(uiBlock *block, PointerRNA *ptr, PropertyRNA *prop, int type, ColorPicker *cpicker)
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
{
uiBut *bt;
int bartype = type + 3;
/* HS square */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButR_prop(block, UI_BTYPE_HSVCUBE, 0, "", 0, PICKER_BAR + PICKER_SPACE, PICKER_TOTAL_W, PICKER_H, ptr, prop, -1, 0.0, 0.0, type, 0, TIP_("Color"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
/* 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
bt = uiDefButR_prop(block, UI_BTYPE_HSVCUBE, 0, "", 0, 0, PICKER_TOTAL_W, PICKER_BAR, ptr, prop, -1, 0.0, 0.0, bartype, 0, TIP_("Value"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
}
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
/* a HS circle, V slider, rgb/hsv/hex sliders */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_colorpicker(uiBlock *block, float rgba[4], PointerRNA *ptr, PropertyRNA *prop, bool show_picker)
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
static short colormode = 0; /* temp? 0=rgb, 1=hsv, 2=hex */
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
uiBut *bt;
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
int width, butwidth;
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
static char tip[50];
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
static char hexcol[128];
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
float rgb_gamma[3];
Code cleanup: quiet warnings & style
2014-04-13 11:26:31 +10:00
unsigned char rgb_gamma_uchar[3];
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
float softmin, softmax, hardmin, hardmax, step, precision;
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
int yco;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
ColorPicker *cpicker = ui_block_colorpicker_create(block);
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
float *hsv = cpicker->color_data;
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
width = PICKER_TOTAL_W;
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
butwidth = width - 1.5f * UI_UNIT_X;
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
- added GCC warning -Wstrict-prototypes - fixed bug in paste material, exposed by stricter warnings. - removed/renamed various shadowed vars. - removed BGE lamp.colour, only allow lamp.color attribute.
2010-12-03 12:30:59 +00:00
/* existence of profile means storage is in linear color space, with display correction */
Fixed (or partly fixed) various missing UI translations, mainly with some specific ops invocations (popup menus…), and (to some extent) with the undo/redo stuff.
2012-04-13 19:59:29 +00:00
/* XXX That tip message is not use anywhere! */
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
if (!block->color_profile) {
Fixed (or partly fixed) various missing UI translations, mainly with some specific ops invocations (popup menus…), and (to some extent) with the undo/redo stuff.
2012-04-13 19:59:29 +00:00
BLI_strncpy(tip, N_("Value in Display Color Space"), sizeof(tip));
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
copy_v3_v3(rgb_gamma, rgba);
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 {
Fixed (or partly fixed) various missing UI translations, mainly with some specific ops invocations (popup menus…), and (to some extent) with the undo/redo stuff.
2012-04-13 19:59:29 +00:00
BLI_strncpy(tip, N_("Value in Linear RGB Color Space"), sizeof(tip));
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
/* make a display version, for Hex code */
copy_v3_v3(rgb_gamma, rgba);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_display_space_v3(block, rgb_gamma);
Make Hex field in colour picker work in gamma corrected space - means that copying Hex values to and from other apps like Photoshop works as expected.
2010-03-15 02:30:53 +00:00
}
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
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
/* sneaky way to check for alpha */
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
rgba[3] = FLT_MAX;
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +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
RNA_property_float_ui_range(ptr, prop, &softmin, &softmax, &step, &precision);
RNA_property_float_range(ptr, prop, &hardmin, &hardmax);
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
RNA_property_float_get_array(ptr, prop, rgba);
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
switch (U.color_picker_type) {
case USER_CP_SQUARE_SV:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_colorpicker_square(block, ptr, prop, UI_GRAD_SV, cpicker);
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
break;
case USER_CP_SQUARE_HS:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_colorpicker_square(block, ptr, prop, UI_GRAD_HS, cpicker);
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
break;
case USER_CP_SQUARE_HV:
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_colorpicker_square(block, ptr, prop, UI_GRAD_HV, cpicker);
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
break;
Code cleanup: de-duplicate switch statement, style edits
2014-03-13 06:18:25 +11:00
/* user default */
case USER_CP_CIRCLE_HSV:
case USER_CP_CIRCLE_HSL:
Anticipate future color picker types and don't crash (uiBut could be NULL in some cases)
2014-03-12 21:06:57 +02:00
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
ui_colorpicker_circle(block, ptr, prop, cpicker);
Anticipate future color picker types and don't crash (uiBut could be NULL in some cases)
2014-03-12 21:06:57 +02:00
break;
Added user preferences for color picker type, includes colour wheel + 3 square types. Find it in prefs -> system
2010-01-09 06:44:54 +00:00
}
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
/* mode */
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
yco = -1.5f * UI_UNIT_Y;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_begin(block);
bt = uiDefButS(block, UI_BTYPE_ROW, 0, IFACE_("RGB"), 0, yco, width / 3, UI_UNIT_Y, &colormode, 0.0, 0.0, 0, 0, "");
UI_but_func_set(bt, ui_colorpicker_create_mode_cb, bt, NULL);
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
bt->custom_data = cpicker;
Fix own bug after HSL picker commit. HSV Cube based pickers missed HSV buttons.
2014-03-13 18:43:04 +02:00
if (U.color_picker_type == USER_CP_CIRCLE_HSL)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButS(block, UI_BTYPE_ROW, 0, IFACE_("HSL"), width / 3, yco, width / 3, UI_UNIT_Y, &colormode, 0.0, 1.0, 0, 0, "");
Fix own bug after HSL picker commit. HSV Cube based pickers missed HSV buttons.
2014-03-13 18:43:04 +02:00
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
bt = uiDefButS(block, UI_BTYPE_ROW, 0, IFACE_("HSV"), width / 3, yco, width / 3, UI_UNIT_Y, &colormode, 0.0, 1.0, 0, 0, "");
UI_but_func_set(bt, ui_colorpicker_create_mode_cb, bt, NULL);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButS(block, UI_BTYPE_ROW, 0, IFACE_("Hex"), 2 * width / 3, yco, width / 3, UI_UNIT_Y, &colormode, 0.0, 2.0, 0, 0, "");
UI_but_func_set(bt, ui_colorpicker_create_mode_cb, bt, NULL);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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);
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00: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
yco = -3.0f * UI_UNIT_Y;
Correction to svn rev50845 Disable color picker button only if color block is invoked from another popup. Only in this case color picking will fail. Valid RNA path isn't required for this, only RNA pointer in button is needed. This solves issue with missing color picking in user preferences.
2012-09-26 10:39:32 +00:00
if (show_picker) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButO(block, UI_BTYPE_BUT, "UI_OT_eyedropper_color", WM_OP_INVOKE_DEFAULT, ICON_EYEDROPPER, butwidth + 10, yco, UI_UNIT_X, UI_UNIT_Y, NULL);
UI_but_func_set(bt, ui_popup_close_cb, bt, NULL);
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
bt->custom_data = cpicker;
Fix #32396: EyeDropper does nothing on "New" in Uv image editor For now simply hide color picker button for properties which doesn't have RNA path. Trying to make color picker working would end up with design limitations like not bale to run two operators the same time. Used RNA_property_path_from_ID_check for check which is marked as slow and need to be used with care. Since this function is only called from a popup, shouldn't be a big problem.
2012-09-24 13:02:08 +00:00
}
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
/* RGB values */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_begin(block);
bt = uiDefButR_prop(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("R:"), 0, yco, butwidth, UI_UNIT_Y, ptr, prop, 0, 0.0, 0.0, 0, 3, TIP_("Red"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButR_prop(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("G:"), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, ptr, prop, 1, 0.0, 0.0, 0, 3, TIP_("Green"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButR_prop(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("B:"), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, ptr, prop, 2, 0.0, 0.0, 0, 3, TIP_("Blue"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
style cleanup: use c style comments in C code
2012-07-06 23:56:59 +00:00
/* could use uiItemFullR(col, ptr, prop, -1, 0, UI_ITEM_R_EXPAND|UI_ITEM_R_SLIDER, "", ICON_NONE);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 need to use UI_but_func_set for updating other fake buttons */
Color Picker work: Restored the old Eyedropper tool from the 2.4 colour picker. Now it's an operator, working nicely using rna properties (fixes #19475 and some todo items) This ended up being a bit more work than expected, it involved converting the colour picker to use RNA properties directly, rather than temporary values. This has several advantages, including being able to type in RGB values greater than 1, however there are still some redraw issues with sliders. Also removed the alternate color pickers after this time spent testing, the current one should be sufficient, or alternatives to the wheel can possibly become preferences in the current design. Converting the picker to RNA also made it very trivial to make a cool new ColorWheel template, which can be embedded in UI layouts. I've enabled it already in texture/vertex paint brush properties and the sequence editor color correction: http://mke3.net/blender/devel/2.5/colorwheels.jpg
2010-01-07 09:55:11 +00:00
/* HSV values */
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
yco = -3.0f * UI_UNIT_Y;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_begin(block);
bt = uiDefButF(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("H:"), 0, yco, butwidth, UI_UNIT_Y, hsv, 0.0, 1.0, 10, 3, TIP_("Hue"));
UI_but_func_set(bt, ui_color_wheel_rna_cb, bt, hsv);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButF(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("S:"), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, hsv + 1, 0.0, 1.0, 10, 3, TIP_("Saturation"));
UI_but_func_set(bt, ui_color_wheel_rna_cb, bt, hsv);
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
bt->custom_data = cpicker;
Fix own bug reported on irc by Venomgfx, missing value slider in color pickers.
2014-03-17 20:01:33 +02:00
if (U.color_picker_type == USER_CP_CIRCLE_HSL)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefButF(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("L:"), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, hsv + 2, 0.0, 1.0, 10, 3, TIP_("Lightness"));
Fix own bug reported on irc by Venomgfx, missing value slider in color pickers.
2014-03-17 20:01:33 +02:00
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
bt = uiDefButF(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("V:"), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, hsv + 2, 0.0, softmax, 10, 3, TIP_("Value"));
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
fix [#36008] Can't set values higher than 1.0 in HSV colour picker (But can in RGB) - also some strange behavior
2013-07-09 04:00:56 +00:00
bt->hardmax = hardmax; /* not common but rgb may be over 1.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_but_func_set(bt, ui_color_wheel_rna_cb, bt, hsv);
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
bt->custom_data = cpicker;
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_align_end(block);
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
if (rgba[3] != FLT_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
bt = uiDefButR_prop(block, UI_BTYPE_NUM_SLIDER, 0, IFACE_("A: "), 0, yco -= UI_UNIT_Y, butwidth, UI_UNIT_Y, ptr, prop, 3, 0.0, 0.0, 0, 3, TIP_("Alpha"));
UI_but_func_set(bt, ui_colorpicker_rna_cb, bt, NULL);
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
bt->custom_data = cpicker;
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
}
else {
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
rgba[3] = 1.0f;
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
}
Code cleanup: quiet warnings & style
2014-04-13 11:26:31 +10:00
rgb_float_to_uchar(rgb_gamma_uchar, rgb_gamma);
Macros: replace UNPACK#OP -> UNPACK#_EX, allow suffix
2014-08-05 08:04:57 +10:00
BLI_snprintf(hexcol, sizeof(hexcol), "%02X%02X%02X", UNPACK3_EX((unsigned int), rgb_gamma_uchar, ));
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00: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
yco = -3.0f * UI_UNIT_Y;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefBut(block, UI_BTYPE_TEXT, 0, IFACE_("Hex: "), 0, yco, butwidth, UI_UNIT_Y, hexcol, 0, 8, 0, 0, TIP_("Hex triplet for color (#RRGGBB)"));
UI_but_func_set(bt, ui_colorpicker_hex_rna_cb, bt, hexcol);
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
bt->custom_data = cpicker;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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, IFACE_("(Gamma Corrected)"), 0, yco - UI_UNIT_Y, butwidth, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +00:00
Slight modification to previous color wheel tweak. Do not use compat version, we do not have a valid previous value really to use here.
2014-04-12 19:27:16 +03:00
ui_rgb_to_color_picker_v(rgb_gamma, hsv);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53: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
ui_colorpicker_hide_reveal(block, colormode);
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
}
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +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_colorpicker_small_wheel_cb(const bContext *UNUSED(C), uiBlock *block, const wmEvent *event)
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
float add = 0.0f;
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (event->type == WHEELUPMOUSE)
add = 0.05f;
else if (event->type == WHEELDOWNMOUSE)
add = -0.05f;
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (add != 0.0f) {
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
uiBut *but;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (but = block->buttons.first; but; but = but->next) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_HSVCUBE && but->active == NULL) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiPopupBlockHandle *popup = block->handle;
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
float rgb[3];
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
ColorPicker *cpicker = but->custom_data;
float *hsv = cpicker->color_data;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 use_display_colorspace = ui_but_is_colorpicker_display_space(but);
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22: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
ui_but_v3_get(but, rgb);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
if (use_display_colorspace)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_display_space_v3(block, rgb);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
ui_rgb_to_color_picker_compat_v(rgb, hsv);
style cleanup: interface
2012-03-30 01:51:25 +00:00
hsv[2] = CLAMPIS(hsv[2] + add, 0.0f, 1.0f);
Fix T39627 HSL sliders jumping. The issue here is that we store HSV in display space. To correctly account for that, made sure HSV/HSL is now using the displayed color to compute the values in the sliders. RGB values still show the property values (linear for linear, gamma corrected for gamma corrected) We could change the way we store HSV uniformly (ie in all the code), but we would need to add many more conversions in the picker code to account for storing it that way. Also it doesn't make sense: Color pickers should help with -visible- color selection. It may be worth changing the RGB sliders as well. My fix takes into account the way HSV is stored in HSVCube as well in the code.
2014-04-07 20:43:47 +03:00
ui_color_picker_to_rgb_v(hsv, rgb);
if (use_display_colorspace)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_cm_to_scene_linear_v3(block, rgb);
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22: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
ui_but_v3_set(but, rgb);
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
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
ui_update_color_picker_buts_rgb(block, cpicker, rgb, !use_display_colorspace);
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 (popup)
style cleanup: interface
2012-03-30 01:51:25 +00:00
popup->menuretval = UI_RETURN_UPDATE;
2.5 Quick Color picker alternative! - only a color circle + value slider - exits immediate after use, or slight mouse move outside picker - use scrollwheel to change HSV 'value'. Also works while picking. - added nicer AA'ed cursor in picker - All color swatches change 'value' on ALT+Wheel mouse-over Old picker is still there, under SHIFT+click on swatch. Needs evaluation... part of UI keymap? Per button type? Or divide picker in left/right? Or just have all those old picker buttons in another panel... I'm not to fond of this giant old popup.
2009-06-12 14:22:27 +00:00
return 1;
}
}
}
return 0;
}
code cleanup: use an enum for uiBut->pointype (more useful debug display of members), and rename COL -> COLOR --- less confusing since the layout engine has row/col's.
2012-09-11 23:10:23 +00:00
uiBlock *ui_block_func_COLOR(bContext *C, uiPopupBlockHandle *handle, void *arg_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
uiBut *but = arg_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
uiBlock *block;
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 show_picker = 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
block = UI_block_begin(C, handle->region, __func__, UI_EMBOSS);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: remove redundant NULL checks
2013-07-31 09:18:40 +00:00
if (RNA_property_subtype(but->rnaprop) == PROP_COLOR_GAMMA) {
block->color_profile = false;
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
}
Correction to svn rev50845 Disable color picker button only if color block is invoked from another popup. Only in this case color picking will fail. Valid RNA path isn't required for this, only RNA pointer in button is needed. This solves issue with missing color picking in user preferences.
2012-09-26 10:39:32 +00:00
if (but->block) {
/* if color block is invoked from a popup we wouldn't be able to set color properly
* this is because color picker will close popups first and then will try to figure
* out active button RNA, and of course it'll fail
*/
show_picker = (but->block->flag & UI_BLOCK_POPUP) == 0;
}
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
replace macros for bli math functions in editors
2011-11-06 16:34:44 +00:00
copy_v3_v3(handle->retvec, but->editvec);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53: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
ui_block_colorpicker(block, handle->retvec, &but->rnapoin, but->rnaprop, show_picker);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
Cleanup: remove unused redraw flag
2014-11-15 14:11:51 +01:00
block->flag = UI_BLOCK_LOOP | UI_BLOCK_KEEP_OPEN | UI_BLOCK_OUT_1 | UI_BLOCK_MOVEMOUSE_QUIT;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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.5 * UI_UNIT_X);
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +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
block->block_event_func = ui_colorpicker_small_wheel_cb;
2.5 Medium sized Color Picker; consisting of number sliders, row buttons to select rgb/hsv/hex, HS circle and V slider. It opens persistant, like old picker. This one opens default, other two can be accessed with ALT or SHIFT click. On todo; - eyedropper tool back - method for click-drag to make mini picker appear Note for UI coders (brecht :), added a UI_HIDDEN flag in buttons, to support switching buttons in menus. Hidden buttons are not activated nor drawn.
2009-06-24 13:44:19 +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
/* and lets go */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
block->direction = UI_DIR_UP;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
}
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
/************************ Popup Menu Memory ****************************/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
static unsigned int ui_popup_string_hash(const char *str)
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
{
/* sometimes button contains hotkey, sometimes not, strip for proper compare */
int hash;
Fix T39884: Displaying filenames with '|' failing in menus
2014-05-01 12:40:49 +10:00
const char *delimit = strrchr(str, UI_SEP_CHAR);
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
GHash: add typed hash functions (were all (void *)) - BLI_ghashutil_strhash_n takes string length, to avoid terminating the string before hashing. - BLI_ghashutil_inthash/uinthash take ints, to avoid casting to (void *) This also showed up incorrect use of inthash, which was using a pointer.
2014-04-15 14:17:54 +10:00
if (delimit) {
hash = BLI_ghashutil_strhash_n(str, delimit - str);
}
else {
hash = BLI_ghashutil_strhash(str);
}
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
return hash;
}
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
static unsigned int ui_popup_menu_hash(const char *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
{
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 BLI_ghashutil_strhash(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
}
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
/* but == NULL read, otherwise set */
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
static uiBut *ui_popup_menu_memory__internal(uiBlock *block, 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: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
static unsigned int mem[256];
error in recent commit
2014-02-13 10:13:33 +11:00
static bool first = true;
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
const unsigned int hash = block->puphash;
const unsigned int hash_mod = hash & 255;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (first) {
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
/* init */
memset(mem, -1, sizeof(mem));
style cleanup: interface
2012-03-30 01:51:25 +00:00
first = 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) {
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
/* set */
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
mem[hash_mod] = ui_popup_string_hash(but->str);
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 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
}
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
else {
/* get */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (but = block->buttons.first; but; but = but->next)
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
if (ui_popup_string_hash(but->str) == mem[hash_mod])
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
return but;
return 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
}
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
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
uiBut *ui_popup_menu_memory_get(uiBlock *block)
{
return ui_popup_menu_memory__internal(block, NULL);
}
void ui_popup_menu_memory_set(uiBlock *block, uiBut *but)
{
ui_popup_menu_memory__internal(block, but);
}
UIL: Dragging popups wasn't updating safe-areas
2014-05-02 09:23:53 +10:00
/**
* Translate any popup regions (so we can drag them).
*/
void ui_popup_translate(bContext *C, ARegion *ar, const int mdiff[2])
{
uiBlock *block;
BLI_rcti_translate(&ar->winrct, UNPACK2(mdiff));
ED_region_update_rect(C, ar);
ED_region_tag_redraw(ar);
/* update blocks */
for (block = ar->uiblocks.first; block; block = block->next) {
uiSafetyRct *saferct;
for (saferct = block->saferct.first; saferct; saferct = saferct->next) {
BLI_rctf_translate(&saferct->parent, UNPACK2(mdiff));
BLI_rctf_translate(&saferct->safety, UNPACK2(mdiff));
}
}
}
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
/******************** Popup Menu with callback or string **********************/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
struct uiPopupMenu {
uiBlock *block;
uiLayout *layout;
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
fix [#35055] Crash in Edit Source feature for multilevel menus dont show the option when operating on a menu since its not supported.
2013-04-23 15:22:22 +00:00
int mx, my;
bool popup, slideout;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
uiMenuCreateFunc menu_func;
void *menu_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
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
struct uiPieMenu {
uiBlock *block_radial; /* radial block of the pie menu (more could be added later) */
uiLayout *layout;
int mx, my;
};
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
static uiBlock *ui_block_func_POPUP(bContext *C, uiPopupBlockHandle *handle, void *arg_pup)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
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
uiBut *bt;
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiPopupMenu *pup = arg_pup;
fix/workaround for v3d object mode selector flipping direction Allow menu functions to define their own direction, this way menu_item_enum_opname_menu can keep menu flipping from 2.69.
2014-02-12 10:29:15 +11:00
int offset[2], minwidth, width, height;
char direction;
bool 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
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 (pup->menu_func) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->block->handle = handle;
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
pup->menu_func(C, pup->layout, pup->menu_arg);
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->block->handle = 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
}
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 (pup->but) {
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
/* minimum width to enforece */
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
minwidth = BLI_rctf_size_x(&pup->but->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
UI: fix for issue in last commit, popups show above the buttons again
2014-02-10 13:44:59 +11:00
/* settings (typically rna-enum-popups) show above the button,
* menu's like file-menu, show below */
fix/workaround for v3d object mode selector flipping direction Allow menu functions to define their own direction, this way menu_item_enum_opname_menu can keep menu flipping from 2.69.
2014-02-12 10:29:15 +11:00
if (pup->block->direction != 0) {
/* allow overriding the direction from menu_func */
direction = pup->block->direction;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 ((pup->but->type == UI_BTYPE_PULLDOWN) ||
(UI_but_menutype_get(pup->but) != NULL))
fix/workaround for v3d object mode selector flipping direction Allow menu functions to define their own direction, this way menu_item_enum_opname_menu can keep menu flipping from 2.69.
2014-02-12 10:29:15 +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
direction = UI_DIR_DOWN;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
direction = UI_DIR_UP;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
minwidth = 50;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
direction = UI_DIR_DOWN;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
flip = (direction == UI_DIR_DOWN);
fix/workaround for v3d object mode selector flipping direction Allow menu functions to define their own direction, this way menu_item_enum_opname_menu can keep menu flipping from 2.69.
2014-02-12 10:29:15 +11:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
block = pup->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
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
/* in some cases we create the block before the region,
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
* so we set it delayed here if necessary */
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 (BLI_findindex(&handle->region->uiblocks, block) == -1)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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, handle->region);
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->direction = direction;
2.5 Simple toolbox-style menu system. Brecht will review it though, and/or check on way to use it for menus. I tried to avoid uiBlock and rna stuff all over. :) Quick image test: http://www.blender.org/bf/rt.jpg Examples you can read in: - editors/screen/screen_ops.c:testing123() (press F5) - editors/object/object_edit.c:object_add_primitive_invoke() (press SHIFT+A) Concept is simple: uiMenuBegin(): returns a handle. uiMenuEnd(): puts it all to work. In between you can add items like: uiMenuItemVal(): a name, icon, retval (use uiMenuFunc()) uiMenuItemO(): an operator + icon uiMenuItemEnumO(): an operator, property name, value Sublevels go easy too: uiMenuLevel(): creates item for sublevel, with function pointer. Inside that function you can use all menu calls again. Levels can go as deep you want. uiMenuLevelEnumO(): creates operator sublevel for an enum
2009-01-25 20:22:05 +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_block_layout_resolve(block, &width, &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
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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);
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (pup->popup) {
Fix for glitch with menus not reliably setting an active item (D674) When menus are clamped to the window bounds, its was possible not to have an active menu-item under the mouse, Making Ctrl+S,Enter not completely reliable. Changes needed to support this are: - menu item is activated on popup menus (to avoid relying on mouse-over) - moving mouse away from menu items only de-activates when over a new menu-item. - Mouse clicks are ignored if they are not directly over the menu item.
2014-08-03 20:30:12 +10:00
uiBut *but_activate = NULL;
Cleanup: remove unused redraw flag
2014-11-15 14:11:51 +01:00
UI_block_flag_enable(block, UI_BLOCK_LOOP | UI_BLOCK_NUMSELECT);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_direction_set(block, direction);
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
/* offset the mouse position, possibly based on earlier selection */
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_POPUP_MEMORY) &&
UI: split ui_popup_menu_memory into get/set functions and store as uint
2014-02-13 09:36:54 +11:00
(bt = ui_popup_menu_memory_get(block)))
style cleanup: interface
2012-03-30 01:51:25 +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
/* position mouse on last clicked item, at 0.8*width of the
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
* button, so it doesn't overlap the text too much, also note
* the offset is negative because we are inverse moving the
* block to be under the mouse */
code cleanup: replace macro for BLI_rect size/center with inline functions.
2012-09-15 11:48:20 +00:00
offset[0] = -(bt->rect.xmin + 0.8f * BLI_rctf_size_x(&bt->rect));
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
offset[1] = -(bt->rect.ymin + 0.5f * UI_UNIT_Y);
Fix for glitch with menus not reliably setting an active item (D674) When menus are clamped to the window bounds, its was possible not to have an active menu-item under the mouse, Making Ctrl+S,Enter not completely reliable. Changes needed to support this are: - menu item is activated on popup menus (to avoid relying on mouse-over) - moving mouse away from menu items only de-activates when over a new menu-item. - Mouse clicks are ignored if they are not directly over the menu item.
2014-08-03 20:30:12 +10:00
if (ui_but_is_editable(bt)) {
but_activate = bt;
}
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
}
else {
/* position mouse at 0.8*width of the button and below the tile
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
* on the first item */
style cleanup: interface
2012-03-30 01:51:25 +00:00
offset[0] = 0;
for (bt = block->buttons.first; bt; bt = bt->next)
rename api functions... - minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
2012-10-23 13:28:22 +00:00
offset[0] = min_ii(offset[0], -(bt->rect.xmin + 0.8f * BLI_rctf_size_x(&bt->rect)));
2.5: Modifiers & Menus * Popup menus now remember the last clicked item again. * Modifier and File Format menus are now organized in multiple columns with categories. * Hook, explode, uv project modifiers have all their buttons again with the relevant operators implemented. * Modifiers that can't be added by the user, or don't work on curves for example, are not in the menu anymore. * Fix search menu overlapping buttons when near the bottom of the screen. * Fix uv layers search menu not working in some modifiers. * Cleanup popup menu code a bit, layout engine is used in more cases now instead of ugly position calculation code.
2009-08-21 02:51:56 +00:00
UI: tweak menu padding and make separator line more visible. Adds some padding to the left of the icon, adds more space around the separator line and make it more visible, and add some spacing at the top and bottom of the menu. Ref T37794 Reviewed By: dingto, billrey Differential Revision: https://developer.blender.org/D223
2014-01-17 00:23:00 +01:00
offset[1] = 2.1 * UI_UNIT_Y;
Fix for glitch with menus not reliably setting an active item (D674) When menus are clamped to the window bounds, its was possible not to have an active menu-item under the mouse, Making Ctrl+S,Enter not completely reliable. Changes needed to support this are: - menu item is activated on popup menus (to avoid relying on mouse-over) - moving mouse away from menu items only de-activates when over a new menu-item. - Mouse clicks are ignored if they are not directly over the menu item.
2014-08-03 20:30:12 +10:00
for (bt = block->buttons.first; bt; bt = bt->next) {
if (ui_but_is_editable(bt)) {
but_activate = bt;
break;
}
}
}
/* in rare cases this is needed since moving the popup
* to be within the window bounds may move it away from the mouse,
* This ensures we set an item to be active. */
if (but_activate) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_over(C, handle->region, but_activate);
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
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->minbounds = minwidth;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_menu(block, 1, offset[0], offset[1]);
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
}
else {
/* for a header menu we set the direction automatic */
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 (!pup->slideout && flip) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
ScrArea *sa = CTX_wm_area(C);
if (sa && sa->headertype == HEADERDOWN) {
ARegion *ar = 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 (ar && ar->regiontype == RGN_TYPE_HEADER) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_direction_set(block, UI_DIR_UP);
UI_block_order_flip(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
}
}
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->minbounds = minwidth;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_text(block, 3.0f * UI_UNIT_X);
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
}
/* if menu slides out of other menu, override direction */
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 (pup->slideout)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_direction_set(block, UI_DIR_RIGHT);
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
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 pup->block;
2.5 Simple toolbox-style menu system. Brecht will review it though, and/or check on way to use it for menus. I tried to avoid uiBlock and rna stuff all over. :) Quick image test: http://www.blender.org/bf/rt.jpg Examples you can read in: - editors/screen/screen_ops.c:testing123() (press F5) - editors/object/object_edit.c:object_add_primitive_invoke() (press SHIFT+A) Concept is simple: uiMenuBegin(): returns a handle. uiMenuEnd(): puts it all to work. In between you can add items like: uiMenuItemVal(): a name, icon, retval (use uiMenuFunc()) uiMenuItemO(): an operator + icon uiMenuItemEnumO(): an operator, property name, value Sublevels go easy too: uiMenuLevel(): creates item for sublevel, with function pointer. Inside that function you can use all menu calls again. Levels can go as deep you want. uiMenuLevelEnumO(): creates operator sublevel for an enum
2009-01-25 20:22:05 +00:00
}
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
uiPopupBlockHandle *ui_popup_menu_create(
bContext *C, ARegion *butregion, uiBut *but,
uiMenuCreateFunc menu_func, void *arg)
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
wmWindow *window = CTX_wm_window(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
uiStyle *style = UI_style_get_dpi();
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
uiPopupBlockHandle *handle;
UI * Headers and menus can now be created in python. * Replaced the uiMenuItem functions to create menus with equivalent uiItem functions using a layout, removing duplicated code. * More uiItem functions are now exposed to python. * The text editor header, panels and one of its menus are now created in space_text.py. * Buttons window data context icon new changes depending on active object. Issues * Icons are not wrapped yet, hardcoded ints at the moment. * The ID browse template is unfinished.
2009-04-22 18:39:44 +00:00
uiPopupMenu *pup;
UI: tweak menu padding and make separator line more visible. Adds some padding to the left of the icon, adds more space around the separator line and make it more visible, and add some spacing at the top and bottom of the menu. Ref T37794 Reviewed By: dingto, billrey Differential Revision: https://developer.blender.org/D223
2014-01-17 00:23:00 +01:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup = MEM_callocN(sizeof(uiPopupMenu), __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
pup->block = UI_block_begin(C, NULL, __func__, UI_EMBOSS_PULLDOWN);
make alphanumeric key shortcuts work for submenu's so you can chain keys together to select items in a menu. eg: 'Ctrl+V, E, S' for - Vertex, Separate, Selection
2012-09-10 06:44:25 +00:00
pup->block->flag |= UI_BLOCK_NUMSELECT; /* default menus to numselect */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
pup->layout = UI_block_layout(pup->block, UI_LAYOUT_VERTICAL, UI_LAYOUT_MENU, 0, 0, 200, 0, MENU_PADDING, style);
fix [#35055] Crash in Edit Source feature for multilevel menus dont show the option when operating on a menu since its not supported.
2013-04-23 15:22:22 +00:00
pup->slideout = but ? ui_block_is_menu(but->block) : false;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->but = but;
UI: * Added some properties of uiLayout that can be set. I've added some API code for more than the two I've implementeds, so ignore those for now. * layout.active = False will gray out buttons inside a layout. * layout.enabled = False will gray out and completely disable the buttons inside a layout. * Also some function renames.
2009-05-28 23:37:55 +00:00
uiLayoutSetOperatorContext(pup->layout, WM_OP_INVOKE_REGION_WIN);
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!but) {
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
/* no button to start from, means we are a popup */
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->mx = window->eventstate->x;
pup->my = window->eventstate->y;
fix [#35055] Crash in Edit Source feature for multilevel menus dont show the option when operating on a menu since its not supported.
2013-04-23 15:22:22 +00:00
pup->popup = true;
Fix [#21529] Operator.report() has inconsistent behaviour with newlines
2010-04-09 07:00:27 +00:00
pup->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
}
revert r40738, flipepd enums give quick access to first items, even if it does seem odd to have them flipped.
2011-10-03 17:59:33 +00:00
/* some enums reversing is strange, currently we have no good way to
* reverse some enum's but not others, so reverse all so the first menu
* items are always close to the mouse cursor */
fix [#28786] Large enum lists display columns in inverted order (right to left) also cleared annoying intel c++ warnings.
2011-10-01 21:09:42 +00:00
else {
Popup menu layout inherits context store from button. When adding extra context data in a layout using uiLayoutSetContextPointer, this info was not inherited by popup menus generated in this layout. While operators from regular buttons work fine, the data is missing in operators from menus and such. This patch copies the bContextStore from buttons to the new uiLayout used for popups.
2012-04-03 15:18:59 +00:00
#if 0
fix [#28786] Large enum lists display columns in inverted order (right to left) also cleared annoying intel c++ warnings.
2011-10-01 21:09:42 +00:00
/* if this is an rna button then we can assume its an enum
* flipping enums is generally not good since the order can be
* important [#28786] */
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_ENUM) {
fix [#28786] Large enum lists display columns in inverted order (right to left) also cleared annoying intel c++ warnings.
2011-10-01 21:09:42 +00:00
pup->block->flag |= UI_BLOCK_NO_FLIP;
}
revert r40738, flipepd enums give quick access to first items, even if it does seem odd to have them flipped.
2011-10-03 17:59:33 +00:00
#endif
Popup menu layout inherits context store from button. When adding extra context data in a layout using uiLayoutSetContextPointer, this info was not inherited by popup menus generated in this layout. While operators from regular buttons work fine, the data is missing in operators from menus and such. This patch copies the bContextStore from buttons to the new uiLayout used for popups.
2012-04-03 15:18:59 +00:00
if (but->context)
uiLayoutContextCopy(pup->layout, but->context);
}
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 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
/* menu is created from a callback */
pup->menu_func = menu_func;
pup->menu_arg = arg;
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
handle = ui_popup_block_create(C, butregion, but, NULL, ui_block_func_POPUP, pup);
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
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) {
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
handle->popup = true;
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 T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(C, &window->modalhandlers, handle, 0);
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
WM_event_add_mousemove(C);
}
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
UI * Headers and menus can now be created in python. * Replaced the uiMenuItem functions to create menus with equivalent uiItem functions using a layout, removing duplicated code. * More uiItem functions are now exposed to python. * The text editor header, panels and one of its menus are now created in space_text.py. * Buttons window data context icon new changes depending on active object. Issues * Icons are not wrapped yet, hardcoded ints at the moment. * The ID browse template is unfinished.
2009-04-22 18:39:44 +00:00
MEM_freeN(pup);
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
return handle;
}
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
/******************** Popup Menu API with begin and end ***********************/
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
/* only return handler, and set optional title */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiPopupMenu *UI_popup_menu_begin(bContext *C, const char *title, int 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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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();
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiPopupMenu *pup = MEM_callocN(sizeof(uiPopupMenu), "popup menu");
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
uiBut *but;
correct sloppy NULL checks, in interface code: - uiPupMenuBegin was checking for NULL title but would still crash if it were NULL. - now tag the function as 'nonnull' and remove NULL checks. make sure NULL isnt passed to it.
2013-07-27 14:17: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
pup->block = UI_block_begin(C, NULL, __func__, UI_EMBOSS_PULLDOWN);
UI: fix for recent menu flipping commit
2014-11-16 17:40:46 +01:00
pup->block->flag |= UI_BLOCK_POPUP_MEMORY | UI_BLOCK_IS_FLIP;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->block->puphash = ui_popup_menu_hash(title);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
pup->layout = UI_block_layout(pup->block, UI_LAYOUT_VERTICAL, UI_LAYOUT_MENU, 0, 0, 200, 0, MENU_PADDING, style);
fix [#30087] operator_context is different for popup and submenu's *TODO, after 2.62* having context different for menu vs submenu is quite confusing, now they are both: WM_OP_INVOKE_REGION_WIN this changes WM_menu_invoke behavior.
2012-10-26 06:22:54 +00:00
/* note, this intentionally differs from the menu & submenu default because many operators
* use popups like this to select one of their options - where having invoke doesn't make sense */
UI: * Added some properties of uiLayout that can be set. I've added some API code for more than the two I've implementeds, so ignore those for now. * layout.active = False will gray out buttons inside a layout. * layout.enabled = False will gray out and completely disable the buttons inside a layout. * Also some function renames.
2009-05-28 23:37:55 +00:00
uiLayoutSetOperatorContext(pup->layout, WM_OP_EXEC_REGION_WIN);
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
/* create in advance so we can let buttons point to retval already */
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->block->handle = MEM_callocN(sizeof(uiPopupBlockHandle), "uiPopupBlockHandle");
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: 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
/* create title button */
correct sloppy NULL checks, in interface code: - uiPupMenuBegin was checking for NULL title but would still crash if it were NULL. - now tag the function as 'nonnull' and remove NULL checks. make sure NULL isnt passed to it.
2013-07-27 14:17:20 +00:00
if (title[0]) {
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
char titlestr[256];
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) {
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_snprintf(titlestr, sizeof(titlestr), " %s", title);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiDefIconTextBut(pup->block, UI_BTYPE_LABEL, 0, icon, titlestr, 0, 0, 200, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
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
}
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
but = uiDefBut(pup->block, UI_BTYPE_LABEL, 0, title, 0, 0, 200, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 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_TEXT_LEFT;
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: tweak menu padding and make separator line more visible. Adds some padding to the left of the icon, adds more space around the separator line and make it more visible, and add some spacing at the top and bottom of the menu. Ref T37794 Reviewed By: dingto, billrey Differential Revision: https://developer.blender.org/D223
2014-01-17 00:23:00 +01:00
uiItemS(pup->layout);
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 * Headers and menus can now be created in python. * Replaced the uiMenuItem functions to create menus with equivalent uiItem functions using a layout, removing duplicated code. * More uiItem functions are now exposed to python. * The text editor header, panels and one of its menus are now created in space_text.py. * Buttons window data context icon new changes depending on active object. Issues * Icons are not wrapped yet, hardcoded ints at the moment. * The ID browse template is unfinished.
2009-04-22 18:39:44 +00:00
return pup;
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
}
/* set the whole structure to work */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_menu_end(bContext *C, uiPopupMenu *pup)
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmWindow *window = CTX_wm_window(C);
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
uiPopupBlockHandle *menu;
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
pup->popup = true;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->mx = window->eventstate->x;
pup->my = window->eventstate->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
style cleanup: interface
2012-03-30 01:51:25 +00:00
menu = ui_popup_block_create(C, NULL, NULL, NULL, ui_block_func_POPUP, pup);
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
menu->popup = true;
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 T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(C, &window->modalhandlers, menu, 0);
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
WM_event_add_mousemove(C);
UI * Headers and menus can now be created in python. * Replaced the uiMenuItem functions to create menus with equivalent uiItem functions using a layout, removing duplicated code. * More uiItem functions are now exposed to python. * The text editor header, panels and one of its menus are now created in space_text.py. * Buttons window data context icon new changes depending on active object. Issues * Icons are not wrapped yet, hardcoded ints at the moment. * The ID browse template is unfinished.
2009-04-22 18:39:44 +00:00
MEM_freeN(pup);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiLayout *UI_popup_menu_layout(uiPopupMenu *pup)
UI * Headers and menus can now be created in python. * Replaced the uiMenuItem functions to create menus with equivalent uiItem functions using a layout, removing duplicated code. * More uiItem functions are now exposed to python. * The text editor header, panels and one of its menus are now created in space_text.py. * Buttons window data context icon new changes depending on active object. Issues * Icons are not wrapped yet, hardcoded ints at the moment. * The ID browse template is unfinished.
2009-04-22 18:39:44 +00:00
{
return pup->layout;
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
}
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
/*************************** Pie Menus ***************************************/
static uiBlock *ui_block_func_PIE(bContext *UNUSED(C), uiPopupBlockHandle *handle, void *arg_pie)
{
uiBlock *block;
uiPieMenu *pie = arg_pie;
int minwidth, width, height;
minwidth = 50;
block = pie->block_radial;
/* in some cases we create the block before the region,
* so we set it delayed here if necessary */
if (BLI_findindex(&handle->region->uiblocks, block) == -1)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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, handle->region);
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
UI_block_layout_resolve(block, &width, &height);
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
Cleanup: remove unused redraw flag
2014-11-15 14:11:51 +01:00
UI_block_flag_enable(block, UI_BLOCK_LOOP | UI_BLOCK_NUMSELECT);
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
block->minbounds = minwidth;
block->bounds = 1;
block->mx = 0;
block->my = 0;
block->bounds_type = UI_BLOCK_BOUNDS_PIE_CENTER;
block->pie_data.pie_center_spawned[0] = pie->mx;
block->pie_data.pie_center_spawned[1] = pie->my;
return pie->block_radial;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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 float ui_pie_menu_title_width(const char *name, int icon)
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: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
const uiFontStyle *fstyle = UI_FSTYLE_WIDGET;
return (UI_fontstyle_string_width(fstyle, name) +
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_UNIT_X * (1.50f + (icon ? 0.25f : 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
uiPieMenu *UI_pie_menu_begin(struct bContext *C, const char *title, int icon, const wmEvent *event)
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
{
Pie menus: Confirm threshold This commit adds a confirm threshold property to pie menus. Basically, this will confirm the pie menu automatically when the distance from the center of the pie exceeds that threshold without a need to release the pie button. The confirm threshold will only work if it is larger than the pie threshold. The confirmation actually occur when the mouse stops moving, to allow multiple pie menus to be better linked together, (see below) This functionality also facilitates the ability for chained pie menus by dragging. Basically, a pie menu item can be a call_menu_pie operator and the new pie menu will still use the original pie menu release event for confirmation. This should allow for quick, gesture based navigation in pie menu hierarchies (going back in the hierarchy is still not supported though) There will be a demonstration pie in the official add-on soon
2014-10-10 19:13:40 +02:00
uiStyle *style;
uiPieMenu *pie;
short event_type;
wmWindow *win = CTX_wm_window(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
style = UI_style_get_dpi();
Pie menus: Confirm threshold This commit adds a confirm threshold property to pie menus. Basically, this will confirm the pie menu automatically when the distance from the center of the pie exceeds that threshold without a need to release the pie button. The confirm threshold will only work if it is larger than the pie threshold. The confirmation actually occur when the mouse stops moving, to allow multiple pie menus to be better linked together, (see below) This functionality also facilitates the ability for chained pie menus by dragging. Basically, a pie menu item can be a call_menu_pie operator and the new pie menu will still use the original pie menu release event for confirmation. This should allow for quick, gesture based navigation in pie menu hierarchies (going back in the hierarchy is still not supported though) There will be a demonstration pie in the official add-on soon
2014-10-10 19:13:40 +02:00
pie = MEM_callocN(sizeof(uiPopupMenu), "pie menu");
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
pie->block_radial = UI_block_begin(C, NULL, __func__, UI_EMBOSS);
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
/* may be useful later to allow spawning pies
* from old positions */
/* pie->block_radial->flag |= UI_BLOCK_POPUP_MEMORY; */
pie->block_radial->puphash = ui_popup_menu_hash(title);
pie->block_radial->flag |= UI_BLOCK_RADIAL;
Pie menus: Confirm threshold This commit adds a confirm threshold property to pie menus. Basically, this will confirm the pie menu automatically when the distance from the center of the pie exceeds that threshold without a need to release the pie button. The confirm threshold will only work if it is larger than the pie threshold. The confirmation actually occur when the mouse stops moving, to allow multiple pie menus to be better linked together, (see below) This functionality also facilitates the ability for chained pie menus by dragging. Basically, a pie menu item can be a call_menu_pie operator and the new pie menu will still use the original pie menu release event for confirmation. This should allow for quick, gesture based navigation in pie menu hierarchies (going back in the hierarchy is still not supported though) There will be a demonstration pie in the official add-on soon
2014-10-10 19:13:40 +02:00
Revert Sticky Keys (and everything related to that) Our current keymap doesn't give us enough room to make such changes in the event system. To fix small issues caused by this, we would need to do drastic changes in Blender's keymaps and internal handling. It was worth a try, but it didn't work. I can write down a more descriptive statement in a few days, but for now I need a break of this stuff.
2015-04-07 14:08:30 +02:00
/* if pie is spawned by a left click, it is always assumed to be click style */
if (event->type == LEFTMOUSE) {
Some corrections to the pie spawning code to account for nested pies.
2014-10-13 19:55:19 +02:00
pie->block_radial->pie_data.flags |= UI_PIE_CLICK_STYLE;
pie->block_radial->pie_data.event = EVENT_NONE;
win->lock_pie_event = EVENT_NONE;
}
else {
Pie menus: * Only use last key for pies if it hasn't been released already * Confirm threshold is now measured as distance after regular threshold. zero disables. * Only display the confirm threshold if there's a valid direction (mouse is after threshold). * Calculate confirm threshold taking recentering into account
2014-10-14 11:57:50 +02:00
if (win->last_pie_event != EVENT_NONE) {
/* original pie key has been released, so don't propagate the event */
if (win->lock_pie_event == EVENT_NONE) {
event_type = EVENT_NONE;
pie->block_radial->pie_data.flags |= UI_PIE_CLICK_STYLE;
}
else
event_type = win->last_pie_event;
}
else {
Some corrections to the pie spawning code to account for nested pies.
2014-10-13 19:55:19 +02:00
event_type = event->type;
Pie menus: * Only use last key for pies if it hasn't been released already * Confirm threshold is now measured as distance after regular threshold. zero disables. * Only display the confirm threshold if there's a valid direction (mouse is after threshold). * Calculate confirm threshold taking recentering into account
2014-10-14 11:57:50 +02:00
}
Some corrections to the pie spawning code to account for nested pies.
2014-10-13 19:55:19 +02:00
pie->block_radial->pie_data.event = event_type;
win->lock_pie_event = event_type;
Fix T41639, hierarchical pie menu - popup interaction is buggy. Basically, this commit changes pie menu click interaction so that confirmation is done on left click release instead of press. This allows dragging on the pie menu to select different items, but most importantly, there should be no left over click events passed on to subsequent menus/pies. This means that pie menus should now be able to spawn popups safely. Also, left clicking to spawn a second pie menu now sets that menu to click style by default allowing for better interaction between hierarhies of pie menus.
2014-10-09 18:37:54 +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
pie->layout = UI_block_layout(pie->block_radial, UI_LAYOUT_VERTICAL, UI_LAYOUT_PIEMENU, 0, 0, 200, 0, 0, style);
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
pie->mx = event->x;
pie->my = event->y;
/* create title button */
if (title[0]) {
Align pie menu title on center.
2014-08-13 14:08:26 +02:00
uiBut *but;
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
char titlestr[256];
int w;
if (icon) {
BLI_snprintf(titlestr, sizeof(titlestr), " %s", title);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
w = ui_pie_menu_title_width(titlestr, icon);
but = uiDefIconTextBut(pie->block_radial, UI_BTYPE_LABEL, 0, icon, titlestr, 0, 0, w, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
}
else {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
w = ui_pie_menu_title_width(title, 0);
but = uiDefBut(pie->block_radial, UI_BTYPE_LABEL, 0, title, 0, 0, w, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
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
}
Align pie menu title on center.
2014-08-13 14:08:26 +02:00
/* do not align left */
but->drawflag &= ~UI_BUT_TEXT_LEFT;
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
}
return pie;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_pie_menu_end(bContext *C, uiPieMenu *pie)
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
{
wmWindow *window = CTX_wm_window(C);
uiPopupBlockHandle *menu;
menu = ui_popup_block_create(C, NULL, NULL, NULL, ui_block_func_PIE, pie);
menu->popup = true;
menu->towardstime = PIL_check_seconds_timer();
Fix T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(
C, &window->modalhandlers,
menu, WM_HANDLER_ACCEPT_DBL_CLICK);
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
WM_event_add_mousemove(C);
MEM_freeN(pie);
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiLayout *UI_pie_menu_layout(uiPieMenu *pie)
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
{
return pie->layout;
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_pie_menu_invoke(struct bContext *C, const char *idname, const wmEvent *event)
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
{
uiPieMenu *pie;
uiLayout *layout;
Menu menu;
MenuType *mt = WM_menutype_find(idname, true);
if (mt == NULL) {
printf("%s: named menu \"%s\" not found\n", __func__, idname);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
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 (mt->poll && mt->poll(C, mt) == 0)
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
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
pie = UI_pie_menu_begin(C, IFACE_(mt->label), ICON_NONE, event);
layout = UI_pie_menu_layout(pie);
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
menu.layout = layout;
menu.type = mt;
if (G.debug & G_DEBUG_WM) {
printf("%s: opening menu \"%s\"\n", __func__, idname);
}
mt->draw(C, &menu);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_pie_menu_end(C, pie);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_INTERFACE;
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
}
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int UI_pie_menu_invoke_from_operator_enum(
struct bContext *C, const char *title, const char *opname,
const char *propname, const wmEvent *event)
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
{
uiPieMenu *pie;
uiLayout *layout;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
pie = UI_pie_menu_begin(C, IFACE_(title), ICON_NONE, event);
layout = UI_pie_menu_layout(pie);
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
layout = uiLayoutRadial(layout);
uiItemsEnumO(layout, opname, propname);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_pie_menu_end(C, pie);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_INTERFACE;
Pie Menus C code backend. This commit merges the code in the pie-menu branch. As per decisions taken the last few days, there are no pie menus included and there will be an official add-on including overrides of some keys with pie menus. However, people will now be able to use the new code in python. Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/ Thanks: Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review and design comments Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for suggestions during the development. Special Thanks to Sean Olson, for his support, suggestions, testing and merciless bugging so that I would finish the pie menu code. Without him we wouldn't be here. Also to the rest of the developers of the original python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who did the research and first implementation and whose code I used to get started.
2014-08-11 10:39:59 +02:00
}
Cleanup: wrapped function indentation
2015-05-05 03:13:47 +10:00
int UI_pie_menu_invoke_from_rna_enum(
struct bContext *C, const char *title, const char *path,
const wmEvent *event)
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
{
PointerRNA ctx_ptr;
PointerRNA r_ptr;
PropertyRNA *r_prop;
uiPieMenu *pie;
uiLayout *layout;
RNA_pointer_create(NULL, &RNA_Context, C, &ctx_ptr);
if (!RNA_path_resolve(&ctx_ptr, path, &r_ptr, &r_prop)) {
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
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
}
/* invalid property, only accept enums */
if (RNA_property_type(r_prop) != PROP_ENUM) {
BLI_assert(0);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
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
pie = UI_pie_menu_begin(C, IFACE_(title), ICON_NONE, event);
Pie menus: Confirm threshold This commit adds a confirm threshold property to pie menus. Basically, this will confirm the pie menu automatically when the distance from the center of the pie exceeds that threshold without a need to release the pie button. The confirm threshold will only work if it is larger than the pie threshold. The confirmation actually occur when the mouse stops moving, to allow multiple pie menus to be better linked together, (see below) This functionality also facilitates the ability for chained pie menus by dragging. Basically, a pie menu item can be a call_menu_pie operator and the new pie menu will still use the original pie menu release event for confirmation. This should allow for quick, gesture based navigation in pie menu hierarchies (going back in the hierarchy is still not supported though) There will be a demonstration pie in the official add-on soon
2014-10-10 19:13:40 +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
layout = UI_pie_menu_layout(pie);
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
layout = uiLayoutRadial(layout);
uiItemFullR(layout, &r_ptr, r_prop, RNA_NO_INDEX, 0, UI_ITEM_R_EXPAND, NULL, 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_pie_menu_end(C, pie);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_INTERFACE;
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
}
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
/*************************** Standard Popup Menus ****************************/
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_menu_reports(bContext *C, ReportList *reports)
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
{
Report *report;
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
uiPopupMenu *pup = NULL;
uiLayout *layout;
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 (!CTX_wm_window(C))
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
return;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (report = reports->list.first; report; report = report->next) {
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
int icon;
const char *msg, *msg_next;
style cleanup
2012-10-14 13:08:19 +00:00
if (report->type < reports->printlevel) {
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
continue;
style cleanup
2012-10-14 13:08:19 +00:00
}
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
if (pup == NULL) {
char title[UI_MAX_DRAW_STR];
BLI_snprintf(title, sizeof(title), "%s: %s", IFACE_("Report"), report->typestr);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
pup = UI_popup_menu_begin(C, title, ICON_NONE);
layout = UI_popup_menu_layout(pup);
style cleanup
2012-10-14 13:08:19 +00:00
}
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
else {
uiItemS(layout);
}
/* split each newline into a label */
msg = report->message;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
icon = UI_icon_from_report_type(report->type);
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
do {
char buf[UI_MAX_DRAW_STR];
msg_next = strchr(msg, '\n');
if (msg_next) {
msg_next++;
BLI_strncpy(buf, msg, MIN2(sizeof(buf), msg_next - msg));
msg = buf;
}
uiItemL(layout, msg, icon);
icon = ICON_NONE;
} while ((msg = msg_next) && *msg);
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: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
if (pup) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_menu_end(C, pup);
UI: improve reports popup - use labels rather then menu items (items selected but did nothing) - each report gets its own icon (icons besides first were ignored) - use uiPupMenu rather then string based menu.
2014-02-09 12:00:03 +11:00
}
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
}
2.5 Simple toolbox-style menu system. Brecht will review it though, and/or check on way to use it for menus. I tried to avoid uiBlock and rna stuff all over. :) Quick image test: http://www.blender.org/bf/rt.jpg Examples you can read in: - editors/screen/screen_ops.c:testing123() (press F5) - editors/object/object_edit.c:object_add_primitive_invoke() (press SHIFT+A) Concept is simple: uiMenuBegin(): returns a handle. uiMenuEnd(): puts it all to work. In between you can add items like: uiMenuItemVal(): a name, icon, retval (use uiMenuFunc()) uiMenuItemO(): an operator + icon uiMenuItemEnumO(): an operator, property name, value Sublevels go easy too: uiMenuLevel(): creates item for sublevel, with function pointer. Inside that function you can use all menu calls again. Levels can go as deep you want. uiMenuLevelEnumO(): creates operator sublevel for an enum
2009-01-25 20:22:05 +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_popup_menu_invoke(bContext *C, const char *idname, ReportList *reports)
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
{
uiPopupMenu *pup;
uiLayout *layout;
* Remember, C-style declarations at the *beginning* of a scope, not C++ style wherever one pleases (before first usage).
2009-10-06 14:09:40 +00:00
Menu menu;
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
MenuType *mt = WM_menutype_find(idname, true);
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (mt == NULL) {
Minor UI messages fixes.
2014-02-22 13:49:40 +01:00
BKE_reportf(reports, RPT_ERROR, "Menu \"%s\" not found", idname);
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (mt->poll && mt->poll(C, mt) == 0)
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_CANCELLED;
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +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
pup = UI_popup_menu_begin(C, IFACE_(mt->label), ICON_NONE);
layout = UI_popup_menu_layout(pup);
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
menu.layout = layout;
menu.type = mt;
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
fix [#30087] operator_context is different for popup and submenu's *TODO, after 2.62* having context different for menu vs submenu is quite confusing, now they are both: WM_OP_INVOKE_REGION_WIN this changes WM_menu_invoke behavior.
2012-10-26 06:22:54 +00:00
if (G.debug & G_DEBUG_WM) {
printf("%s: opening menu \"%s\"\n", __func__, idname);
}
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +00:00
mt->draw(C, &menu);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_menu_end(C, pup);
UI: report if WM_OT_call_menu uses an unknown menu
2014-02-10 14:17:33 +11:00
Fix T41041: 'Delete keyframe' removes markers too Operators that trigger UI events (but nothing else) were using 'CANCELLED' making it impossible to tell if an invoke function failed, or opened a menu.
2014-10-28 17:51:06 +01:00
return OPERATOR_INTERFACE;
new operator - bpy.ops.wm.call_menu(name="SOME_MT_menu") This calls a registered menu as a popup so we can reuse header menus , currently used for Node editor and Sequencer add menu (Shift+A), can be used for toolbox too.
2009-10-06 13:04:31 +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
/*************************** Popup Block API **************************/
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_block_invoke_ex(bContext *C, uiBlockCreateFunc func, void *arg, const char *opname, int opcontext)
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
wmWindow *window = CTX_wm_window(C);
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
uiPopupBlockHandle *handle;
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = ui_popup_block_create(C, NULL, NULL, func, NULL, arg);
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
handle->popup = true;
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->optype = (opname) ? WM_operatortype_find(opname, 0) : NULL;
handle->opcontext = opcontext;
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
Fix T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(C, &window->modalhandlers, handle, 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
WM_event_add_mousemove(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
void UI_popup_block_invoke(bContext *C, uiBlockCreateFunc func, void *arg)
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
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_block_invoke_ex(C, func, arg, NULL, WM_OP_INVOKE_DEFAULT);
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
}
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_block_ex(bContext *C, uiBlockCreateFunc func, uiBlockHandleFunc popup_func, uiBlockCancelFunc cancel_func, void *arg)
merge from trunk #37722
2011-06-24 03:30:50 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmWindow *window = CTX_wm_window(C);
merge from trunk #37722
2011-06-24 03:30:50 +00:00
uiPopupBlockHandle *handle;
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = ui_popup_block_create(C, NULL, NULL, func, NULL, arg);
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
handle->popup = true;
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->retvalue = 1;
merge from trunk #37722
2011-06-24 03:30:50 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->popup_arg = arg;
handle->popup_func = popup_func;
handle->cancel_func = cancel_func;
style cleanup
2012-05-27 19:40:36 +00:00
// handle->opcontext = opcontext;
merge from trunk #37722
2011-06-24 03:30:50 +00:00
Fix T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(C, &window->modalhandlers, handle, 0);
merge from trunk #37722
2011-06-24 03:30:50 +00:00
WM_event_add_mousemove(C);
}
#if 0 /* UNUSED */
2.5 - Added new popup menu type, which can be used to pass on a running operator too. Needed it for debug menu, allowing to set variables outside of operator "first do then tweak" system. :) void uiPupBlockOperator() Don't forget to tell invoke() return that operator now runs modal! - Test menu: alt+ctrl+d gives the G.rt debug value. Values of 0-16 now can be used to shrink areas, stuff like this then happens (rt==4): http://download.blender.org/institute/rt5.jpg Was looking at ways to visually distinguish areas and regions better. Yes I know, cute rounded corners, etc. Just testing!
2009-05-22 15:02:32 +00:00
void uiPupBlockOperator(bContext *C, uiBlockCreateFunc func, wmOperator *op, int opcontext)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmWindow *window = CTX_wm_window(C);
2.5 - Added new popup menu type, which can be used to pass on a running operator too. Needed it for debug menu, allowing to set variables outside of operator "first do then tweak" system. :) void uiPupBlockOperator() Don't forget to tell invoke() return that operator now runs modal! - Test menu: alt+ctrl+d gives the G.rt debug value. Values of 0-16 now can be used to shrink areas, stuff like this then happens (rt==4): http://download.blender.org/institute/rt5.jpg Was looking at ways to visually distinguish areas and regions better. Yes I know, cute rounded corners, etc. Just testing!
2009-05-22 15:02:32 +00:00
uiPopupBlockHandle *handle;
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = ui_popup_block_create(C, NULL, NULL, func, NULL, op);
handle->popup = 1;
handle->retvalue = 1;
2.5 - Added new popup menu type, which can be used to pass on a running operator too. Needed it for debug menu, allowing to set variables outside of operator "first do then tweak" system. :) void uiPupBlockOperator() Don't forget to tell invoke() return that operator now runs modal! - Test menu: alt+ctrl+d gives the G.rt debug value. Values of 0-16 now can be used to shrink areas, stuff like this then happens (rt==4): http://download.blender.org/institute/rt5.jpg Was looking at ways to visually distinguish areas and regions better. Yes I know, cute rounded corners, etc. Just testing!
2009-05-22 15:02:32 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->popup_arg = op;
handle->popup_func = operator_cb;
handle->cancel_func = confirm_cancel_operator;
handle->opcontext = opcontext;
2.5 - Added new popup menu type, which can be used to pass on a running operator too. Needed it for debug menu, allowing to set variables outside of operator "first do then tweak" system. :) void uiPupBlockOperator() Don't forget to tell invoke() return that operator now runs modal! - Test menu: alt+ctrl+d gives the G.rt debug value. Values of 0-16 now can be used to shrink areas, stuff like this then happens (rt==4): http://download.blender.org/institute/rt5.jpg Was looking at ways to visually distinguish areas and regions better. Yes I know, cute rounded corners, etc. Just testing!
2009-05-22 15:02:32 +00:00
Fix T44747: Drag toggle /w nodes (glitch) It was possible to perform actions while performing a drag-toggle.
2015-06-01 16:40:43 +10:00
UI_popup_handlers_add(C, &window->modalhandlers, handle, 0);
2.5 - Added new popup menu type, which can be used to pass on a running operator too. Needed it for debug menu, allowing to set variables outside of operator "first do then tweak" system. :) void uiPupBlockOperator() Don't forget to tell invoke() return that operator now runs modal! - Test menu: alt+ctrl+d gives the G.rt debug value. Values of 0-16 now can be used to shrink areas, stuff like this then happens (rt==4): http://download.blender.org/institute/rt5.jpg Was looking at ways to visually distinguish areas and regions better. Yes I know, cute rounded corners, etc. Just testing!
2009-05-22 15:02:32 +00:00
WM_event_add_mousemove(C);
}
merge from trunk #37722
2011-06-24 03:30:50 +00:00
#endif
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
Alternative fix copying windows from popup dialogs It could still crash if the window was freed and another was activated. see T44688.
2015-06-08 15:57:42 +10:00
void UI_popup_block_close(bContext *C, wmWindow *win, 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
{
Fix operator exec /w popups that close the window Related to T44688, note supporting this case isn't so nice, but seems it can be made to work.
2015-06-02 18:57:52 +10:00
/* if loading new .blend while popup is open, window will be NULL */
Alternative fix copying windows from popup dialogs It could still crash if the window was freed and another was activated. see T44688.
2015-06-08 15:57:42 +10:00
if (block->handle) {
if (win) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some 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_popup_handlers_remove(&win->modalhandlers, block->handle);
Fix #30155: crash with popup menu open while new .blend file is loaded, CTX_wm_window is then set to NULL and checked in the event queue, but it should be checked for removing handlers too.
2012-02-13 21:05:04 +00:00
ui_popup_block_free(C, block->handle);
}
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
ColorPicker *ui_block_colorpicker_create(struct uiBlock *block)
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
{
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
ColorPicker *cpicker = MEM_callocN(sizeof(ColorPicker), "color_picker");
BLI_addhead(&block->color_pickers.list, cpicker);
return cpicker;
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
}
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
void ui_rgb_to_color_picker_compat_v(const float rgb[3], float r_cp[3])
{
switch (U.color_picker_type) {
case USER_CP_CIRCLE_HSL:
rgb_to_hsl_compat_v(rgb, r_cp);
break;
default:
rgb_to_hsv_compat_v(rgb, r_cp);
break;
}
}
Slight modification to previous color wheel tweak. Do not use compat version, we do not have a valid previous value really to use here.
2014-04-12 19:27:16 +03:00
void ui_rgb_to_color_picker_v(const float rgb[3], float r_cp[3])
{
switch (U.color_picker_type) {
case USER_CP_CIRCLE_HSL:
rgb_to_hsl_v(rgb, r_cp);
break;
default:
rgb_to_hsv_v(rgb, r_cp);
break;
}
}
HSL color wheel implementation. This is a standard Hue - Saturation - Lightness model (see for instance entry on wikipedia here: https://en.wikipedia.org/wiki/HSL_and_HSV) Note though the difference between HSV and HSL saturation, which are not the same. The advantage of having this color selection scheme is that artists can select shades and tints of a color easily by using the lightness slider. Also colors are arranged on (approximated) perceived lightness on the color wheel. Beware, Old files opened with this preference saved will crash! Reviewers: sergey, brecht, campbellbarton Differential Revision: https://developer.blender.org/D385
2014-03-12 18:58:50 +02:00
void ui_color_picker_to_rgb_v(const float r_cp[3], float rgb[3])
{
switch (U.color_picker_type) {
case USER_CP_CIRCLE_HSL:
hsl_to_rgb_v(r_cp, rgb);
break;
default:
hsv_to_rgb_v(r_cp, rgb);
break;
}
}
void ui_color_picker_to_rgb(float r_cp0, float r_cp1, float r_cp2, float *r, float *g, float *b)
{
switch (U.color_picker_type) {
case USER_CP_CIRCLE_HSL:
hsl_to_rgb(r_cp0, r_cp1, r_cp2, r, g, b);
break;
default:
hsv_to_rgb(r_cp0, r_cp1, r_cp2, r, g, b);
break;
}
}
Copy Permalink