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

2784 lines
76 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
*/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: 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: Error reporting * Added a report list to operator, to which they can report errors and warnings. When the operator ends, it will display them with a popup. For python these should become exceptions when calling operators. * Added a function to make a popup menu from a report list. * Also added a utility function to prepend a string before the reports to indicate what they relates to. Also made the report functions used BLI_dynstr to simplify the code. * Made file reading and writing report errors to the user again using this system, also replacing the left over uncommented bad level error() calls.
2008-12-29 13:38:08 +00:00
#include "BLI_dynstr.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
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"
#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"
#include "wm_window.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"
i18n: code clean-up - Move all translation-related declarations to BLF_translation.h - Reverted some changes to match trunk svn rev40365
2011-09-20 07:39:25 +00:00
#include "BLF_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"
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
#define MENU_SEPR_HEIGHT 6
#define B_NOP -1
#define MENU_SHADOW_SIDE 8
#define MENU_SHADOW_BOTTOM 10
#define MENU_TOP 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
/*********************** Menu Data Parsing ********************* */
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
typedef struct MenuEntry {
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
const char *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
int retval;
int icon;
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
int sepr;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
} MenuEntry;
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
typedef struct MenuData {
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
const char *instr;
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
const char *title;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 titleicon;
MenuEntry *items;
int nitems, itemssize;
} MenuData;
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
static MenuData *menudata_new(const char *instr)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
MenuData *md = MEM_mallocN(sizeof(*md), "MenuData");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
md->instr = instr;
md->title = NULL;
md->titleicon = 0;
md->items = NULL;
md->nitems = md->itemssize = 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
return md;
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
static void menudata_set_title(MenuData *md, const char *title, int titleicon)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (!md->title)
style cleanup: interface
2012-03-30 01:51:25 +00:00
md->title = title;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (!md->titleicon)
style cleanup: interface
2012-03-30 01:51:25 +00:00
md->titleicon = titleicon;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
static void menudata_add_item(MenuData *md, const char *str, int retval, int icon, int sepr)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (md->nitems == md->itemssize) {
int nsize = md->itemssize ? (md->itemssize << 1) : 1;
MenuEntry *oitems = md->items;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
md->items = MEM_mallocN(nsize * sizeof(*md->items), "md->items");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (oitems) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
memcpy(md->items, oitems, md->nitems * sizeof(*md->items));
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(oitems);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
md->itemssize = nsize;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
md->items[md->nitems].str = str;
md->items[md->nitems].retval = retval;
md->items[md->nitems].icon = icon;
md->items[md->nitems].sepr = sepr;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
md->nitems++;
}
many functions in blender are not marked static but should be. most local modifier,GPU,ImBuf and Interface functions are now static. also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
2011-02-13 14:16:36 +00:00
static void menudata_free(MenuData *md)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
MEM_freeN((void *)md->instr);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (md->items) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(md->items);
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
MEM_freeN(md);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
/**
* Parse menu description strings, string is of the
* form "[sss%t|]{(sss[%xNN]|), (%l|), (sss%l|)}", ssss%t indicates the
* menu title, sss or sss%xNN indicates an option,
* if %xNN is given then NN is the return value if
* that option is selected otherwise the return value
* is the index of the option (starting with 1). %l
* indicates a seperator, sss%l indicates a label and
* new column.
*
* \param str String to be parsed.
* \retval new menudata structure, free with menudata_free()
*/
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
static MenuData *decompose_menu_string(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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *instr = BLI_strdup(str);
MenuData *md = menudata_new(instr);
const char *nitem = NULL;
char *s = instr;
int nicon = 0, nretval = 1, nitem_is_title = 0, nitem_is_sepr = 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
while (1) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
char c = *s;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (c == '%') {
if (s[1] == 'x') {
nretval = atoi(s + 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
*s = '\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
s++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (s[1] == 't') {
nitem_is_title = (s != instr); /* check for empty title */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
*s = '\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
s++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (s[1] == 'l') {
nitem_is_sepr = 1;
if (!nitem) nitem = "";
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
*s = '\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
s++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (s[1] == 'i') {
nicon = atoi(s + 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
*s = '\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
s++;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (c == '|' || c == '\n' || c == '\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
if (nitem) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
*s = '\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 (nitem_is_title) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
menudata_set_title(md, nitem, nicon);
style cleanup: interface
2012-03-30 01:51:25 +00:00
nitem_is_title = 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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (nitem_is_sepr) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* prevent separator to get a value */
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
menudata_add_item(md, nitem, -1, nicon, 1);
style cleanup: interface
2012-03-30 01:51:25 +00:00
nretval = md->nitems + 1;
nitem_is_sepr = 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
}
else {
menudata_add_item(md, nitem, nretval, nicon, 0);
style cleanup: interface
2012-03-30 01:51:25 +00:00
nretval = md->nitems + 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
nitem = NULL;
nicon = 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (c == '\0') {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
minor changes to interface code (no functional changes) - made 2 loops on menu items break out of the loop when the item is found. - include function names in error prints.
2011-09-27 17:04:38 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else if (!nitem) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
nitem = s;
minor changes to interface code (no functional changes) - made 2 loops on menu items break out of the loop when the item is found. - include function names in error prints.
2011-09-27 17:04:38 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
s++;
}
return md;
}
void ui_set_name_menu(uiBut *but, int value)
{
MenuData *md;
int i;
style cleanup: interface
2012-03-30 01:51:25 +00:00
md = decompose_menu_string(but->str);
for (i = 0; i < md->nitems; i++) {
if (md->items[i].retval == value) {
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_strncpy(but->drawstr, md->items[i].str, sizeof(but->drawstr));
minor changes to interface code (no functional changes) - made 2 loops on menu items break out of the loop when the item is found. - include function names in error prints.
2011-09-27 17:04:38 +00:00
break;
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53: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
menudata_free(md);
}
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
int ui_step_name_menu(uiBut *but, int step)
{
MenuData *md;
style cleanup: interface
2012-03-30 01:51:25 +00:00
int value = ui_get_but_val(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
int i;
style cleanup: interface
2012-03-30 01:51:25 +00:00
md = decompose_menu_string(but->str);
for (i = 0; i < md->nitems; i++)
if (md->items[i].retval == value)
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
break;
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (step == 1) {
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
/* skip separators */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (; i < md->nitems - 1; i++) {
if (md->items[i + 1].retval != -1) {
value = md->items[i + 1].retval;
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
break;
}
}
}
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (i > 0) {
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
/* skip separators */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (; i > 0; i--) {
if (md->items[i - 1].retval != -1) {
value = md->items[i - 1].retval;
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
break;
}
}
}
}
menudata_free(md);
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
/******************** Creating Temporary regions ******************/
many functions in blender are not marked static but should be. most local modifier,GPU,ImBuf and Interface functions are now static. also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
2011-02-13 14:16:36 +00:00
static ARegion *ui_add_temporary_region(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;
}
many functions in blender are not marked static but should be. most local modifier,GPU,ImBuf and Interface functions are now static. also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
2011-02-13 14:16:36 +00:00
static void ui_remove_temporary_region(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
{
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: 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
wm_draw_region_clear(CTX_wm_window(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
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 **********************/
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
typedef enum {
UI_TIP_LC_MAIN,
UI_TIP_LC_NORMAL,
UI_TIP_LC_PYTHON,
UI_TIP_LC_ALERT,
UI_TIP_LC_SUBMENU
} uiTooltipLineColor;
#define UI_TIP_LC_MAX 5
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;
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
char lines[MAX_TOOLTIP_LINES][512];
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
uiTooltipLineColor color_id[MAX_TOOLTIP_LINES];
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;
int toth, spaceh, 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;
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
static void rgb_tint(float col[3],
float h, float h_strength,
float v, float v_strength)
{
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
{
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 */
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 *submenu_color = tip_colors[UI_TIP_LC_SUBMENU];
float background_color[3];
float tone_bg;
int i;
/* draw background */
ui_draw_tooltip_background(UI_GetStyle(), NULL, &bbox);
/* 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);
copy_v3_v3(normal_color, main_color);
copy_v3_v3(python_color, main_color);
copy_v3_v3(alert_color, main_color);
copy_v3_v3(submenu_color, main_color);
/* 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
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
tone_bg = rgb_to_grayscale(background_color);
/* tone_fg = rgb_to_grayscale(main_color); */
rgb_tint(normal_color, 0.0f, 0.0f, tone_bg, 0.3f); /* a shade darker (to bg) */
rgb_tint(python_color, 0.666f, 0.25f, tone_bg, 0.3f); /* blue */
rgb_tint(alert_color, 0.0f, 0.8f, tone_bg, 0.1f); /* bright red */
rgb_tint(submenu_color, 0.0f, 0.0f, tone_bg, 0.3f); /* a shade darker (to bg) */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
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
uiStyleFontSet(&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
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
bbox.ymax = bbox.ymax - 0.5f * (BLI_RCT_SIZE_Y(&bbox) - data->toth);
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
bbox.ymin = bbox.ymax - data->lineh;
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++) {
glColor3fv(tip_colors[data->color_id[i]]);
uiStyleFontDraw(&data->fstyle, &bbox, data->lines[i]);
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
bbox.ymin -= data->lineh + data->spaceh;
bbox.ymax -= data->lineh + data->spaceh;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiStyle *style = UI_GetStyle();
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];
style cleanup: interface
2012-03-30 01:51:25 +00:00
float fonth, fontw, aspect = but->block->aspect;
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
int winx, winy, ofsx, ofsy, w, h, a;
rctf rect_fl;
rcti rect_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 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
const int nbr_info = 6;
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};
uiStringInfo rna_struct = {BUT_GET_RNASTRUCT_IDENTIFIER, NULL};
uiStringInfo rna_prop = {BUT_GET_RNAPROP_IDENTIFIER, 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 (but->flag & 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 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
uiButGetStrInfo(C, but, nbr_info, &but_tip, &enum_label, &enum_tip, &op_keymap, &rna_struct, &rna_prop);
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
/* special case, enum rna buttons only have enum item description,
* use general enum description too before the specific one */
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 0
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop && RNA_property_type(but->rnaprop) == PROP_ENUM) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
const char *descr = RNA_property_description(but->rnaprop);
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 (descr && descr[0]) {
Added tooltip note that parent curve 'Follow' needs to be enabled for track axis to do anything. also show both enum descriptions in the tooltip (the enum properties description and the individual enums).
2011-04-28 13:01:29 +00:00
BLI_strncpy(data->lines[data->totline], descr, sizeof(data->lines[0]));
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
data->color_id[data->totline] = UI_TIP_LC_MAIN;
Added tooltip note that parent curve 'Follow' needs to be enabled for track axis to do anything. also show both enum descriptions in the tooltip (the enum properties description and the individual enums).
2011-04-28 13:01:29 +00:00
data->totline++;
}
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +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 (ELEM(but->type, ROW, MENU)) {
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
EnumPropertyItem *item;
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
int totitem, free;
code cleanup: double promotion warnings
2012-05-22 21:16:59 +00:00
int value = (but->type == ROW) ? (int)but->hardmax : (int)ui_get_but_val(but);
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
Fixing issues with i18n stuff: - Make gettext stuff draw-time. so switching between languages can happens without restart now. - Added option to translate visible interface (menus, buttons, labels) and tooltips. Now it's possible to have english UI and localized tooltips. - Clean-up sources, do not use gettext stuff for things which can be collected with RNA. - Fix issues with windows 64bit and ru_RU locale on my desktop (it was codepage issue). - Added operator "Get Messages" which generates new text block with with all strings collected from RNA. - Changed script for updating blender.pot so now it appends messages collected from rna to automatically gathered messages. To update .pot you have to re-generate messages.txt using "Get Messages" operator and then run update_pot script. - Clean up old translation stuff which wasn't used and most probably wouldn't be used. - Return back "International Fonts" option, so if it's disabled, no gettext lookups happens on draw. - Merged read_homefile function back. No need in splitting it. TODO: - Custom fonts and font size. Current font isn't nice at least for russian locale, it's difficult to read it. - Put references to messages.txt so gettext can merge translation when name/description of some property changes.
2011-09-15 13:20:18 +00:00
RNA_property_enum_items_gettexted(C, &but->rnapoin, but->rnaprop, &item, &totitem, &free);
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (i = 0; i < totitem; i++) {
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 (item[i].identifier[0] && item[i].value == value) {
if (item[i].description && item[i].description[0]) {
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), "%s: %s",
item[i].name, item[i].description);
style cleanup: pep8, indentation
2012-03-24 07:36:32 +00:00
data->color_id[data->totline] = UI_TIP_LC_SUBMENU;
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
data->totline++;
}
break;
}
}
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
if (free) {
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
MEM_freeN(item);
style chang, made mainly because I wanted to be able to add breakpoints to MEM_freeN calls which were on the same line as the if's.
2012-01-21 22:00:40 +00:00
}
UI: fix two issues with expanded enum property buttons: * they were too slow for dynamic python enums, calling the callback to list the items for each button, to get a tooltip * enum tooltips sometimes were showing the same description twice
2011-06-02 14:18:51 +00:00
}
Added tooltip note that parent curve 'Follow' needs to be enabled for track axis to do anything. also show both enum descriptions in the tooltip (the enum properties description and the individual enums).
2011-04-28 13:01:29 +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->tip && but->tip[0] != '\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
BLI_strncpy(data->lines[data->totline], but->tip, sizeof(data->lines[0]));
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
data->color_id[data->totline] = UI_TIP_LC_MAIN;
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
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
#else
/* Tip */
if (but_tip.strinfo) {
BLI_strncpy(data->lines[data->totline], but_tip.strinfo, sizeof(data->lines[0]));
data->color_id[data->totline] = UI_TIP_LC_MAIN;
data->totline++;
}
/* Enum item label & tip */
if (enum_label.strinfo && enum_tip.strinfo) {
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]),
"%s: %s", enum_label.strinfo, enum_tip.strinfo);
data->color_id[data->totline] = UI_TIP_LC_SUBMENU;
data->totline++;
}
#endif
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 0
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->optype && !(but->block->flag & UI_BLOCK_LOOP)) {
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
/* operator keymap (not menus, they already have it) */
style cleanup: interface
2012-03-30 01:51:25 +00:00
prop = (but->opptr) ? but->opptr->data : NULL;
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 (WM_key_event_operator_string(C, but->optype->idname, but->opcontext, prop, TRUE,
style cleanup: interface
2012-03-30 01:51:25 +00:00
buf, sizeof(buf)))
replace fixed sizes with sizeof when passing string length since size wasn't always correct.
2012-01-12 13:16:30 +00:00
{
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_("Shortcut: %s"), buf);
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
data->color_id[data->totline] = 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++;
}
}
UI translation from inside Blender UI: first part. This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator. It also adds a few getters (to get RNA i18n context, and current language iso code). Finally, it adds to C operators needed for the py ui_translation addon: *UI_OT_edittranslation_init, which gathers requested data and launch the py operator. *UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files). For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
#else
/* Op shortcut */
if (op_keymap.strinfo) {
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Shortcut: %s"), op_keymap.strinfo);
data->color_id[data->totline] = UI_TIP_LC_NORMAL;
data->totline++;
}
#endif
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 (ELEM3(but->type, TEX, IDPOIN, SEARCH_MENU)) {
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
/* full string */
ui_get_but_string(but, buf, sizeof(buf));
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (buf[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_("Value: %s"), buf);
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
data->color_id[data->totline] = UI_TIP_LC_NORMAL;
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
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
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (but->rnaprop) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
int unit_type = uiButGetUnitType(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);
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
data->color_id[data->totline] = 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);
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
data->color_id[data->totline] = 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++;
}
}
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 0
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
/* rna info */
User preference to hide Python references in Tooltips.
2010-11-22 00:10:32 +00:00
if ((U.flag & USER_TOOLTIPS_PYTHON) == 0) {
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Python: %s.%s"),
RNA_struct_identifier(but->rnapoin.type), RNA_property_identifier(but->rnaprop));
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
data->color_id[data->totline] = UI_TIP_LC_PYTHON;
User preference to hide Python references in Tooltips.
2010-11-22 00:10:32 +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
#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 (but->rnapoin.id.data) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
ID *id = but->rnapoin.id.data;
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 (id->lib && id->lib->name) {
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);
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
data->color_id[data->totline] = 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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
opptr = uiButGetOperatorPtrRNA(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) */
WM_operator_properties_sanitize(opptr, FALSE);
style cleanup: interface
2012-03-30 01:51:25 +00:00
str = WM_operator_pystring(C, but->optype, opptr, 0);
- 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);
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
data->color_id[data->totline] = 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);
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
data->color_id[data->totline] = UI_TIP_LC_ALERT; /* 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 0
include menu ID's in tooltips when python tips are enabled, there was no way to find the ID of a menu which become annoying if you wanted to reference it from a script.
2011-07-26 09:19:51 +00:00
else if (ELEM(but->type, MENU, PULLDOWN)) {
if ((U.flag & USER_TOOLTIPS_PYTHON) == 0) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
MenuType *mt = uiButGetMenuType(but);
fix [#29242] menus have no keyboard shortcuts
2011-11-14 14:42:47 +00:00
if (mt) {
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"), mt->idname);
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
data->color_id[data->totline] = UI_TIP_LC_PYTHON;
include menu ID's in tooltips when python tips are enabled, there was no way to find the ID of a menu which become annoying if you wanted to reference it from a script.
2011-07-26 09:19:51 +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
#else
if ((U.flag & USER_TOOLTIPS_PYTHON) == 0 && !but->optype && rna_struct.strinfo) {
if (rna_prop.strinfo)
/* Struct and prop */
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]),
TIP_("Python: %s.%s"), rna_struct.strinfo, rna_prop.strinfo);
else
/* Only struct (e.g. menus) */
BLI_snprintf(data->lines[data->totline], sizeof(data->lines[0]), TIP_("Python: %s"), rna_struct.strinfo);
data->color_id[data->totline] = UI_TIP_LC_PYTHON;
data->totline++;
}
#endif
/* 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);
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
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
assert(data->totline < MAX_TOOLTIP_LINES);
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = ui_add_temporary_region(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;
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 */
data->fstyle.align = UI_STYLE_TEXT_CENTER;
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
uiStyleFontSet(&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
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
/* these defines may need to be tweaked depending on font */
#define TIP_MARGIN_Y 2
#define TIP_BORDER_X 16.0f
#define TIP_BORDER_Y 6.0f
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0, fontw = 0, fonth = 0; a < data->totline; a++) {
w = BLF_width(data->fstyle.uifont_id, data->lines[a]);
fontw = MAX2(fontw, w);
fonth += (a == 0) ? h : h + TIP_MARGIN_Y;
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
}
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
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;
data->spaceh = TIP_MARGIN_Y;
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
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
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
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: 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
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 + but->rect.xmax) * 0.5f + ofsx - (TIP_BORDER_X * aspect);
rect_fl.xmax = rect_fl.xmin + fontw + (TIP_BORDER_X * aspect);
rect_fl.ymax = but->rect.ymin + ofsy - (TIP_BORDER_Y * aspect);
rect_fl.ymin = rect_fl.ymax - fonth * aspect - (TIP_BORDER_Y * aspect);
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
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
#undef TIP_MARGIN_Y
#undef TIP_BORDER_X
#undef 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
/* 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 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
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) {
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
/* XXX temp, region v2ds can be empty still */
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) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
UI_view2d_to_region_no_clip(&butregion->v2d, rect_fl.xmin, rect_fl.ymin, &rect_i.xmin, &rect_i.ymin);
UI_view2d_to_region_no_clip(&butregion->v2d, rect_fl.xmax, rect_fl.ymax, &rect_i.xmax, &rect_i.ymax);
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
}
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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 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
wm_window_get_size(CTX_wm_window(C), &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
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
/* widget rect, in region coords */
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.xmin = MENU_SHADOW_SIDE;
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
data->bbox.xmax = BLI_RCT_SIZE_X(&rect_i) + MENU_SHADOW_SIDE;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.ymin = MENU_SHADOW_BOTTOM;
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
data->bbox.ymax = BLI_RCT_SIZE_Y(&rect_i) + MENU_SHADOW_BOTTOM;
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
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
/* region bigger for shadow */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
ar->winrct.xmin = rect_i.xmin - MENU_SHADOW_SIDE;
ar->winrct.xmax = rect_i.xmax + MENU_SHADOW_SIDE;
ar->winrct.ymin = rect_i.ymin - MENU_SHADOW_BOTTOM;
ar->winrct.ymax = rect_i.ymax + MENU_TOP;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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)
{
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_remove_temporary_region(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 */
int noback; /* when menu opened with enough space for this */
int preview; /* draw thumbnail previews, rather than list */
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 */
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 uiSearchItemAdd(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 * 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_do_name(items->autocpl, name);
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
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++;
return 1;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (items->totitem >= items->maxitem) {
items->more = 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
return 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
}
/* 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--;
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
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++;
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
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
}
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 uiSearchBoxhHeight(void)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
return SEARCH_ITEMS * UI_UNIT_Y + 2 * 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
/* 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (data->items.totitem == 0)
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
else if (data->active > data->items.totitem) {
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++;
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->active = data->items.totitem;
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_update(C, ar, but, 0);
}
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->active = data->items.totitem;
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 if (data->active < 1) {
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--;
style cleanup: interface
2012-03-30 01:51:25 +00:00
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
ui_searchbox_update(C, ar, but, 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
else if (data->active < 0)
style cleanup: interface
2012-03-30 01:51:25 +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
ED_region_tag_redraw(ar);
}
static void ui_searchbox_butrect(rcti *rect, uiSearchboxData *data, int itemnr)
{
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) {
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
int butw = BLI_RCT_SIZE_X(&data->bbox) / data->prv_cols;
int buth = (BLI_RCT_SIZE_Y(&data->bbox) - 2 * MENU_TOP) / 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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
*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;
rect->xmin += col * butw;
rect->xmax = rect->xmin + butw;
Bugfix #26483 Two small draw fixes to make the giant preview-image search-menu draw correctly. (previews were drawing over a button)
2011-03-17 14:52:01 +00:00
rect->ymax = data->bbox.ymax - MENU_TOP - (row * 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
rect->ymin = rect->ymax - buth;
}
/* list view */
else {
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
int buth = (BLI_RCT_SIZE_Y(&data->bbox) - 2 * 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
style cleanup: interface
2012-03-30 01:51:25 +00:00
*rect = data->bbox;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
rect->xmin = data->bbox.xmin + 3.0f;
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
style cleanup: interface
2012-03-30 01:51:25 +00:00
rect->ymax = data->bbox.ymax - MENU_TOP - itemnr * buth;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
rect->ymin = 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
}
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 */
int ui_searchbox_inside(ARegion *ar, int x, int y)
{
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: rename BLI_in_rctf() --> BLI_rctf_isect_pt(), to conform with our naming convention.
2012-08-23 18:25:45 +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) */
void ui_searchbox_apply(uiBut *but, ARegion *ar)
{
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
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->active) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *name = data->items.names[data->active - 1];
char *cpoin = strchr(name, '|');
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
if (cpoin) cpoin[0] = 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
BLI_strncpy(but->editstr, name, data->items.maxstrlen);
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (cpoin) cpoin[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
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->func_arg2 = data->items.pointers[data->active - 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
}
}
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
void ui_searchbox_event(bContext *C, ARegion *ar, uiBut *but, 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;
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
switch (event->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)) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (data->active != a + 1) {
data->active = a + 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
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 */
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
void ui_searchbox_update(bContext *C, ARegion *ar, uiBut *but, int 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;
if (reset == 0) {
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;
data->active = 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
/* 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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->active = data->items.offset_i + 1;
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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->active = 1 + data->items.offset_i - data->items.totitem + data->items.maxitem;
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;
data->active = 1 + 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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (reset && 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
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++) {
char *cpoin = strchr(data->items.names[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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (cpoin) cpoin[0] = 0;
if (0 == strcmp(but->editstr, data->items.names[a]))
data->active = a + 1;
if (cpoin) cpoin[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
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (data->items.totitem == 1 && but->editstr[0])
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
}
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);
}
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
void ui_searchbox_autocomplete(bContext *C, ARegion *ar, uiBut *but, char *str)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiSearchboxData *data = ar->regiondata;
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]) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->items.autocpl = autocomplete_begin(str, ui_get_but_string_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
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
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
}
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmOrtho2(-0.01f, ar->winx - 0.01f, -0.01f, ar->winy - 0.01f);
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 (!data->noback)
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 */
if (data->preview)
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_draw_preview_item(&data->fstyle, &rect, data->items.names[a], data->items.icons[a], (a + 1) == 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
else
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_draw_menu_item(&data->fstyle, &rect, data->items.names[a], data->items.icons[a], (a + 1) == 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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ui_draw_menu_item(&data->fstyle, &rect, data->items.names[a], data->items.icons[a], (a + 1) == 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
}
/* 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: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
UI_icon_draw((BLI_RCT_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: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
UI_icon_draw((BLI_RCT_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)
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiStyle *style = UI_GetStyle();
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;
int winx, winy, ofsx, ofsy;
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = ui_add_temporary_region(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;
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);
uiStyleFontSet(&data->fstyle);
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 */
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->block->flag & UI_BLOCK_LOOP)
style cleanup: interface
2012-03-30 01:51:25 +00:00
data->noback = 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
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) {
data->preview = 1;
data->prv_rows = but->a1;
data->prv_cols = but->a2;
}
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 */
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->block->flag & UI_BLOCK_LOOP) {
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 */
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.xmin = MENU_SHADOW_SIDE;
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
data->bbox.xmax = BLI_RCT_SIZE_X(&ar->winrct) - MENU_SHADOW_SIDE;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.ymin = MENU_SHADOW_BOTTOM;
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
data->bbox.ymax = BLI_RCT_SIZE_Y(&ar->winrct) - MENU_SHADOW_BOTTOM;
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 */
macros for rectangle center and size
2012-08-20 15:29:02 +00:00
if (but->rect.ymax < BLI_RCT_CENTER_Y(&but->block->rect)) {
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
data->bbox.ymin += BLI_RCT_SIZE_Y(&but->rect);
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 {
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
data->bbox.ymax -= BLI_RCT_SIZE_Y(&but->rect);
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 {
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;
rect_fl.ymin = rect_fl.ymax - uiSearchBoxhHeight();
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 */
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
if (BLI_RCT_SIZE_X(&rect_fl) < 150) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
rect_fl.xmax = rect_fl.xmin + 150; /* XXX arbitrary */
}
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) {
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
UI_view2d_to_region_no_clip(&butregion->v2d, rect_fl.xmin, rect_fl.ymin, &rect_i.xmin, &rect_i.ymin);
UI_view2d_to_region_no_clip(&butregion->v2d, rect_fl.xmax, rect_fl.ymax, &rect_i.xmax, &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
}
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
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
wm_window_get_size(CTX_wm_window(C), &winx, &winy);
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) {
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
int newy1;
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
UI_view2d_to_region_no_clip(&butregion->v2d, 0, but->rect.ymax + ofsy, NULL, &newy1);
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: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
rect_i.ymax = BLI_RCT_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 */
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.xmin = MENU_SHADOW_SIDE;
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
data->bbox.xmax = BLI_RCT_SIZE_X(&rect_i) + MENU_SHADOW_SIDE;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
data->bbox.ymin = MENU_SHADOW_BOTTOM;
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
data->bbox.ymax = BLI_RCT_SIZE_Y(&rect_i) + MENU_SHADOW_BOTTOM;
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 */
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
ar->winrct.xmin = rect_i.xmin - MENU_SHADOW_SIDE;
ar->winrct.xmax = rect_i.xmax + MENU_SHADOW_SIDE;
ar->winrct.ymin = rect_i.ymin - MENU_SHADOW_BOTTOM;
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_remove_temporary_region(C, CTX_wm_screen(C), ar);
}
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... */
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
void ui_but_search_test(uiBut *but)
{
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (items->totitem == 0)
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
uiButSetFlag(but, UI_BUT_REDALERT);
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (items->more == 0) {
for (x1 = 0; x1 < items->totitem; x1++)
if (strcmp(but->drawstr, items->names[x1]) == 0)
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
break;
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (x1 == items->totitem)
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
uiButSetFlag(but, UI_BUT_REDALERT);
}
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 */
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
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_block_to_window_fl(butregion, but->block, &butrct.xmin, &butrct.ymin);
ui_block_to_window_fl(butregion, but->block, &butrct.xmax, &butrct.ymax);
/* 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
}
}
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
/* aspect = (float)(BLI_RCT_SIZE_X(&block->rect) + 4);*/ /*UNUSED*/
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
ui_block_to_window_fl(butregion, but->block, &block->rect.xmin, &block->rect.ymin);
ui_block_to_window_fl(butregion, but->block, &block->rect.xmax, &block->rect.ymax);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
code cleanup: use BLI_RCT_SIZE macro
2012-08-20 23:06:17 +00:00
xsize = BLI_RCT_SIZE_X(&block->rect) + 4; /* 4 for shadow */
ysize = BLI_RCT_SIZE_Y(&block->rect) + 4;
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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
int 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
wm_window_get_size(window, &winx, &winy);
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (block->direction & UI_CENTER) 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
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
dir1 = block->direction & UI_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
/* secundary directions */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir1 & (UI_TOP | UI_DOWN)) {
if (dir1 & UI_LEFT) dir2 = UI_LEFT;
else if (dir1 & UI_RIGHT) dir2 = UI_RIGHT;
dir1 &= (UI_TOP | UI_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
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir2 == 0) if (dir1 == UI_LEFT || dir1 == UI_RIGHT) dir2 = UI_DOWN;
if (dir2 == 0) if (dir1 == UI_TOP || dir1 == UI_DOWN) dir2 = UI_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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir1 == UI_LEFT && left == 0) dir1 = UI_RIGHT;
if (dir1 == UI_RIGHT && right == 0) dir1 = UI_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! */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir2 == UI_LEFT && right == 0) dir2 = UI_RIGHT;
if (dir2 == UI_RIGHT && left == 0) dir2 = UI_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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (dir1 == UI_TOP && top == 0) dir1 = UI_DOWN;
if (dir1 == UI_DOWN && down == 0) dir1 = UI_TOP;
if (dir2 == UI_TOP && top == 0) dir2 = UI_DOWN;
if (dir2 == UI_DOWN && down == 0) dir2 = UI_TOP;
}
if (dir1 == UI_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;
if (dir2 == UI_TOP) yof = butrct.ymin - block->rect.ymin - center;
else yof = butrct.ymax - block->rect.ymax + center;
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
else if (dir1 == UI_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;
if (dir2 == UI_TOP) yof = butrct.ymin - block->rect.ymin - center;
else yof = butrct.ymax - block->rect.ymax + center;
style cleanup: interface
2012-03-30 01:51:25 +00:00
}
else if (dir1 == UI_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
yof = butrct.ymax - block->rect.ymin;
if (dir2 == UI_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) {
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->direction & UI_SHIFT_FLIPPED)
style cleanup: interface
2012-03-30 01:51:25 +00:00
xof += dir2 == UI_LEFT ? 25 : -25;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
uiBlockFlipOrder(block);
}
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (dir1 == UI_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;
if (dir2 == UI_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) {
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->direction & UI_SHIFT_FLIPPED)
style cleanup: interface
2012-03-30 01:51:25 +00:00
xof += dir2 == UI_LEFT ? 25 : -25;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
uiBlockFlipOrder(block);
}
}
/* 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) {
if (dir1 == UI_LEFT || dir1 == UI_RIGHT) {
style cleanup
2012-08-19 10:41:27 +00:00
/* align with bottom of screen */
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
// 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) {
if (dir1 == UI_TOP || dir1 == UI_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
}
}
style cleanup
2012-08-19 10:41:27 +00:00
/* apply requested offset in the block */
style cleanup: interface
2012-03-30 01:51:25 +00:00
xof += block->xofs / block->aspect;
yof += block->yofs / block->aspect;
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) {
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
ui_block_to_window_fl(butregion, but->block, &bt->rect.xmin, &bt->rect.ymin);
ui_block_to_window_fl(butregion, but->block, &bt->rect.xmax, &bt->rect.ymax);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00:00
bt->aspect = 1.0f;
/* ui_check_but recalculates drawstring size in pixels */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_check_but(bt);
}
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
{
macros for rectangle center and size
2012-08-20 15:29:02 +00:00
const float midx = BLI_RCT_CENTER_X(&butrct);
const float midy = BLI_RCT_CENTER_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) {
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 (dir2 == UI_RIGHT) block->safety.xmax = block->rect.xmax + 3;
if (dir2 == UI_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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (block = ar->uiblocks.first; block; block = block->next)
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
uiDrawBlock(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)
{
int winx, winy;
wm_window_get_size(window, &winx, &winy);
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 < MENU_SHADOW_SIDE)
block->rect.xmin = MENU_SHADOW_SIDE;
if (block->rect.xmax > winx - MENU_SHADOW_SIDE)
block->rect.xmax = winx - MENU_SHADOW_SIDE;
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
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.ymin < MENU_SHADOW_BOTTOM)
block->rect.ymin = MENU_SHADOW_BOTTOM;
if (block->rect.ymax > winy - MENU_TOP)
block->rect.ymax = winy - MENU_TOP;
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;
Fix [#29018] Problem with multi-column dorpdown lists, when scrolling is enabled: the bottom-most elements are not shown. ui_popup_block_scrolltest needs to be aware whether uiblock is flip or not, to avoid hiding irrelevant items in multi-column scrolled menus...
2011-11-18 23:10:56 +00:00
/* Knowing direction is necessary for multi-column menus... */
int is_flip = (block->direction & UI_TOP) && !(block->flag & UI_BLOCK_NO_FLIP);
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
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;
/* mark buttons that are outside boundary and the ones next to it for arrow(s) */
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;
/* make space for arrow */
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.ymin + 10) {
if (is_flip && bt->next && bt->next->rect.ymin > bt->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->next->flag |= UI_SCROLLED;
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
else if (!is_flip && bt->prev && bt->prev->rect.ymin > bt->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->prev->flag |= UI_SCROLLED;
}
}
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;
/* make space for arrow */
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.ymax - 10) {
if (!is_flip && bt->next && bt->next->rect.ymax < bt->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->next->flag |= UI_SCROLLED;
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
else if (is_flip && bt->prev && bt->prev->rect.ymax < bt->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->prev->flag |= UI_SCROLLED;
}
}
}
}
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
uiPopupBlockHandle *ui_popup_block_create(bContext *C, ARegion *butregion, uiBut *but,
uiBlockCreateFunc create_func, uiBlockHandleCreateFunc handle_create_func,
void *arg)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
wmWindow *window = CTX_wm_window(C);
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;
uiBlock *block;
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
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
uiSafetyRct *saferct;
/* create handle */
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = MEM_callocN(sizeof(uiPopupBlockHandle), "uiPopupBlockHandle");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 F6 menu "redo last operation" now works, mostly :) Try it in editmode on add-UV-Sphere, or Subdivide, those work fine. Transform ops have some feedback issues or so. This is a temporary commit; brecht will take this further with nice code (event system doesn't make menus as active region but sets the original context instead, as stored in ui handler.)
2009-02-07 16:43:55 +00:00
/* store context for operator */
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->ctx_area = CTX_wm_area(C);
handle->ctx_region = CTX_wm_region(C);
2.5 F6 menu "redo last operation" now works, mostly :) Try it in editmode on add-UV-Sphere, or Subdivide, those work fine. Transform ops have some feedback issues or so. This is a temporary commit; brecht will take this further with nice code (event system doesn't make menus as active region but sets the original context instead, as stored in ui handler.)
2009-02-07 16:43:55 +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
/* create area region */
style cleanup: interface
2012-03-30 01:51:25 +00:00
ar = ui_add_temporary_region(CTX_wm_screen(C));
handle->region = 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 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
memset(&type, 0, sizeof(ARegionType));
style cleanup: interface
2012-03-30 01:51:25 +00:00
type.draw = ui_block_region_draw;
ar->type = &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
UI: don't use operators anymore for handling user interface events, but rather a special UI handler which makes the code clearer. This UI handler is attached to the region along with other handlers, and also gets a callback when all handlers for the region are removed to ensure things are properly cleaned up. This should fix XXX's in the UI code related to events and context switching. Most of the changes are in interface_handlers.c, which was renamed from interface_ops.c, to convert operators to the UI handler. UI code notes: * uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is required to properly cancel things like timers or tooltips when the region gets removed. * UI_add_region_handlers will add the region level UI handlers, to be used when adding keymap handlers etc. This replaces the UI keymap. * When the UI code starts a modal interaction (number sliding, text editing, opening a menu, ..), it will add an UI handler at the window level which will block events. Windowmanager changes: * Added an UI handler next to the existing keymap and operator modal handlers. It has an event handling and remove callback, and like operator modal handlers will remember the area and region if it is registered at the window level. * Removed the MESSAGE event. * Operator cancel and UI handler remove callbacks now get the window/area/region restored in the context, like the operator modal and UI handler event callbacks. * Regions now receive MOUSEMOVE events for the mouse going outside of the region. This was already happening for areas, but UI buttons are at the region level so we need it there. Issues: * Tooltips and menus stay open when switching to another window, and button highlight doesn't work without moving the mouse first when Blender starts up. I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to arrive.. * Timeline header buttons seem to be moving one pixel or so sometimes when interacting with them. * Seems not due to this commit, but UI and keymap handlers are leaking. It seems that handlers are being added to regions in all screens, also in regions of areas that are not visible, but these handlers are not removed. Probably there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
UI_add_region_handlers(&ar->handlers);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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)
style cleanup: interface
2012-03-30 01:51:25 +00:00
block = create_func(C, handle->region, 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
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
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
/* set UI_BLOCK_NUMSELECT before uiEndBlock() so we get alphanumeric keys assigned */
if (but) {
if (but->type == PULLDOWN) {
block->flag |= UI_BLOCK_NUMSELECT;
}
}
else {
block->flag |= UI_BLOCK_POPUP | UI_BLOCK_NUMSELECT;
}
block->flag |= UI_BLOCK_LOOP;
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)
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
uiEndBlock(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
/* 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) {
if (ELEM(but->type, BLOCK, PULLDOWN))
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->xofs = -2; /* for proper alignment */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 #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);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 {
/* 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);
}
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
/* clip block with window boundary */
ui_popup_block_clip(window, 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
/* 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.
Some tweaks to menu drawing
2009-01-04 00:05:40 +00:00
* additionally we add some padding for the menu shadow or rounded menus */
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
ar->winrct.xmin = block->rect.xmin - MENU_SHADOW_SIDE;
ar->winrct.xmax = block->rect.xmax + MENU_SHADOW_SIDE;
ar->winrct.ymin = block->rect.ymin - MENU_SHADOW_BOTTOM;
ar->winrct.ymax = block->rect.ymax + MENU_TOP;
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
code cleanup: use BLI rect functions for interface button and block code.
2012-08-18 18:11:51 +00: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
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);
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: 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
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
wm_subwindow_getmatrix(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
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
{
2.5 internal bugfix: remove modal handlers before exiting the screen, since these may be using it.
2009-11-23 11:49:23 +00:00
ui_remove_temporary_region(C, CTX_wm_screen(C), handle->region);
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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (handle->scrolltimer)
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
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
MEM_freeN(handle);
}
/***************************** Menu Button ***************************/
- 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_block_func_MENUSTR(bContext *UNUSED(C), uiLayout *layout, void *arg_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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiBlock *block = uiLayoutGetBlock(layout);
uiPopupBlockHandle *handle = block->handle;
uiLayout *split, *column = 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
uiBut *bt;
MenuData *md;
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
MenuEntry *entry;
style cleanup: interface
2012-03-30 01:51:25 +00:00
const char *instr = arg_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
int columns, rows, a, b;
style cleanup: interface
2012-03-30 01:51:25 +00:00
int column_start = 0, column_end = 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
Splash screen, implemented by Matt. * Now has documentation links and recent files. * Click on image or outside splash to make it go away. * Still has old image, new one will be committed later.
2009-11-23 13:58:55 +00:00
uiBlockSetFlag(block, UI_BLOCK_MOVEMOUSE_QUIT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 menu data */
style cleanup: interface
2012-03-30 01:51:25 +00:00
md = decompose_menu_string(instr);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* columns and row estimation */
style cleanup: interface
2012-03-30 01:51:25 +00:00
columns = (md->nitems + 20) / 20;
if (columns < 1)
columns = 1;
if (columns > 8)
columns = (md->nitems + 25) / 25;
rows = md->nitems / columns;
if (rows < 1)
rows = 1;
while (rows * columns < md->nitems)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
rows++;
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
/* create title */
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 (md->title) {
if (md->titleicon) {
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
uiItemL(layout, md->title, md->titleicon);
}
else {
== UI icons == * Change ICON_NULL --> ICON_NONE to avoid two #defines with the same meaning.
2011-02-27 18:03:19 +00:00
uiItemL(layout, md->title, ICON_NONE);
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = block->buttons.last;
bt->flag = UI_TEXT_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
}
}
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
/* inconsistent, but menus with labels do not look good flipped */
style cleanup: interface
2012-03-30 01:51:25 +00:00
entry = md->items;
for (a = 0; a < md->nitems; a++, entry++) {
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 (entry->sepr && entry->str[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
block->flag |= UI_BLOCK_NO_FLIP;
minor changes to interface code (no functional changes) - made 2 loops on menu items break out of the loop when the item is found. - include function names in error prints.
2011-09-27 17:04:38 +00:00
break;
}
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
}
/* create items */
style cleanup: use TRUE/FALSE for ui align args.
2012-06-19 23:08:16 +00:00
split = uiLayoutSplit(layout, 0.0f, FALSE);
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
for (a = 0; a < md->nitems; a++) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (a == column_end) {
Fix #29762: columns in long enum property menu's were in the wrong order.
2012-01-17 16:06:16 +00:00
/* start new column, and find out where it ends in advance, so we
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
* can flip the order of items properly per column */
style cleanup: interface
2012-03-30 01:51:25 +00:00
column_start = a;
column_end = md->nitems;
Fix #29762: columns in long enum property menu's were in the wrong order.
2012-01-17 16:06:16 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (b = a + 1; b < md->nitems; b++) {
entry = &md->items[b];
Fix #29762: columns in long enum property menu's were in the wrong order.
2012-01-17 16:06:16 +00:00
/* new column on N rows or on separation label */
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (((b - a) % rows == 0) || (entry->sepr && entry->str[0])) {
Fix #29762: columns in long enum property menu's were in the wrong order.
2012-01-17 16:06:16 +00:00
column_end = b;
break;
}
}
style cleanup: use TRUE/FALSE for ui align args.
2012-06-19 23:08:16 +00:00
column = uiLayoutColumn(split, FALSE);
Fix #29762: columns in long enum property menu's were in the wrong order.
2012-01-17 16:06:16 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (block->flag & UI_BLOCK_NO_FLIP)
style cleanup: interface
2012-03-30 01:51:25 +00:00
entry = &md->items[a];
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
entry = &md->items[column_start + column_end - 1 - a];
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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 (entry->sepr) {
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
uiItemL(column, entry->str, entry->icon);
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = block->buttons.last;
bt->flag = UI_TEXT_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
else if (entry->icon) {
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
uiDefIconTextButF(block, BUTM, B_NOP, entry->icon, entry->str, 0, 0,
style cleanup: interface
2012-03-30 01:51:25 +00:00
UI_UNIT_X * 5, UI_UNIT_Y, &handle->retvalue, (float) entry->retval, 0.0, 0, 0, "");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else {
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
uiDefButF(block, BUTM, B_NOP, entry->str, 0, 0,
style cleanup: interface
2012-03-30 01:51:25 +00:00
UI_UNIT_X * 5, UI_UNIT_X, &handle->retvalue, (float) entry->retval, 0.0, 0, 0, "");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
menudata_free(md);
}
- 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
void ui_block_func_ICONROW(bContext *UNUSED(C), uiLayout *layout, 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
uiBlock *block = uiLayoutGetBlock(layout);
uiPopupBlockHandle *handle = block->handle;
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
int a;
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
uiBlockSetFlag(block, UI_BLOCK_MOVEMOUSE_QUIT);
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = (int)but->hardmin; a <= (int)but->hardmax; a++)
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
uiDefIconButF(block, BUTM, B_NOP, but->icon + (a - but->hardmin), 0, 0, UI_UNIT_X * 5, UI_UNIT_Y,
style cleanup: interface
2012-03-30 01:51:25 +00:00
&handle->retvalue, (float)a, 0.0, 0, 0, "");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
- 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
void ui_block_func_ICONTEXTROW(bContext *UNUSED(C), uiLayout *layout, 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
uiBlock *block = uiLayoutGetBlock(layout);
uiPopupBlockHandle *handle = block->handle;
uiBut *but = arg_but, *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
MenuData *md;
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
MenuEntry *entry;
int a;
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
uiBlockSetFlag(block, UI_BLOCK_MOVEMOUSE_QUIT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
md = decompose_menu_string(but->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
/* title */
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 (md->title) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefBut(block, LABEL, 0, md->title, 0, 0, UI_UNIT_X * 5, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
bt->flag = UI_TEXT_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
}
/* loop through the menu options and draw them out with icons & text labels */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (a = 0; a < md->nitems; a++) {
entry = &md->items[md->nitems - a - 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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (entry->sepr)
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
uiItemS(layout);
else
code cleanup: changing the INT define to an enum conflicts with INT typedef on windows, use more verbose names for button pointer types. also removed some redundant flags from buttons.
2012-09-12 00:32:33 +00:00
uiDefIconTextButF(block, BUTM, B_NOP, (short)((but->icon) + (entry->retval - but->hardmin)), entry->str,
style cleanup: interface
2012-03-30 01:51:25 +00:00
0, 0, UI_UNIT_X * 5, UI_UNIT_Y, &handle->retvalue, (float) entry->retval, 0.0, 0, 0, "");
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 More font style work; - hooked up almost all ui buttons code to new font system, including text clipping - panel headers scale now too to smaller fonts - added further style hints, for shadow/emboss. Is all going to be in UI designer control! - for fun; changed layout engine to spread vertical buttons in window width Next: removal of all usage of old font system, using 'styles'. Will also move font blurring to blenfont module.
2009-04-10 14:06:24 +00:00
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
menudata_free(md);
}
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 ****************/
/* picker sizes S hsize, F full size, D spacer, B button/pallette height */
style cleanup: interface
2012-03-30 01:51:25 +00:00
#define SPICK 110.0
#define FPICK 180.0
#define DPICK 6.0
#define BPICK 24.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
/* for picker, while editing hsv */
void ui_set_but_hsv(uiBut *but)
{
float col[3];
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *hsv = ui_block_hsv_get(but->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
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(hsv, 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
ui_set_but_vectorf(but, col);
}
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
/* also used by small picker, be careful with name checks below... */
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
static void ui_update_block_buts_rgb(uiBlock *block, const 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
{
uiBut *bt;
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *hsv = ui_block_hsv_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
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!
*/
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_compat_v(rgb, hsv);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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) {
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_set_but_vectorf(bt, rgb);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (strcmp(bt->str, "Hex: ") == 0) {
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];
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) */
if (block->color_profile == BLI_PR_NONE) {
copy_v3_v3(rgb_gamma, rgb);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
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
/* make an sRGB version, for Hex code */
linearrgb_to_srgb_v3_v3(rgb_gamma, rgb);
}
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);
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
BLI_snprintf(col, sizeof(col), "%02X%02X%02X",
FTOCHAR(rgb_gamma[0]), FTOCHAR(rgb_gamma[1]), FTOCHAR(rgb_gamma[2]));
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') {
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
ui_set_but_val(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') {
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
ui_set_but_val(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') {
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
ui_set_but_val(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') {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_set_but_val(bt, hsv[0]);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (bt->str[0] == 'S') {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_set_but_val(bt, hsv[1]);
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
else if (bt->str[0] == 'V') {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_set_but_val(bt, hsv[2]);
}
}
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_check_but(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
}
}
- 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 do_picker_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);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
ui_update_block_buts_rgb(but->block, rgb);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
}
- 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 do_hsv_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];
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *hsv = ui_block_hsv_get(but->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
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(hsv, rgb);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
ui_update_block_buts_rgb(but->block, rgb);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
}
- 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 do_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;
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) */
if (but->block->color_profile != BLI_PR_NONE) {
/* so we need to linearise it for Blender */
srgb_to_linearrgb_v3_v3(rgb, rgb);
}
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
ui_update_block_buts_rgb(but->block, rgb);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
}
- 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 close_popup_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
}
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
static void picker_new_hide_reveal(uiBlock *block, short colormode)
{
uiBut *bt;
/* tag buttons */
style cleanup: interface
2012-03-30 01:51:25 +00:00
for (bt = block->buttons.first; bt; bt = bt->next) {
fix for error in own recent commit: do not hide alpha in HSV and Hex modes
2012-09-08 19:40:34 +00:00
if (bt->func == do_picker_rna_cb && bt->type == NUMSLI && bt->rnaindex != 3) {
/* 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
}
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
else if (bt->func == do_hsv_rna_cb) {
/* HSV sliders */
if (colormode == 1) bt->flag &= ~UI_HIDDEN;
else bt->flag |= UI_HIDDEN;
}
else if (bt->func == do_hex_rna_cb || bt->type == LABEL) {
/* 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
}
}
}
- 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 do_picker_new_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;
short colormode = ui_get_but_val(bt);
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
picker_new_hide_reveal(bt->block, colormode);
}
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
/* picker sizes S hsize, F full size, D spacer, B button/pallette height */
style cleanup: interface
2012-03-30 01:51:25 +00:00
#define SPICK1 150.0
#define DPICK1 6.0
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_H 150
#define PICKER_W 150
#define PICKER_SPACE 6
#define PICKER_BAR 14
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
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
static void circle_picker(uiBlock *block, PointerRNA *ptr, PropertyRNA *prop)
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefButR_prop(block, HSVCIRCLE, 0, "", 0, 0, PICKER_H, PICKER_W, ptr, prop, 0, 0.0, 0.0, 0, 0, "Color");
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
/* value */
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefButR_prop(block, HSVCUBE, 0, "", PICKER_W + PICKER_SPACE, 0, PICKER_BAR, PICKER_H, ptr, prop, 0, 0.0, 0.0, UI_GRAD_V_ALT, 0, "Value");
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
}
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
static void square_picker(uiBlock *block, PointerRNA *ptr, PropertyRNA *prop, int type)
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefButR_prop(block, HSVCUBE, 0, "", 0, PICKER_BAR + PICKER_SPACE, PICKER_TOTAL_W, PICKER_H, ptr, prop, 0, 0.0, 0.0, type, 0, "Color");
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
/* value */
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefButR_prop(block, HSVCUBE, 0, "", 0, 0, PICKER_TOTAL_W, PICKER_BAR, ptr, prop, 0, 0.0, 0.0, bartype, 0, "Value");
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
}
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 */
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
static void uiBlockPicker(uiBlock *block, float rgba[4], PointerRNA *ptr, PropertyRNA *prop)
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];
Fix [#22278] Colour Balance Node HSV Value slider range is insufficient.
2010-05-24 02:05:23 +00:00
float min, max, step, precision;
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *hsv = ui_block_hsv_get(block);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
ui_block_hsv_get(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
style cleanup: interface
2012-03-30 01:51:25 +00:00
width = PICKER_TOTAL_W;
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
butwidth = width - UI_UNIT_X - 10;
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! */
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
if (block->color_profile == BLI_PR_NONE) {
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));
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
/* make an sRGB version, for Hex code */
use 'const float' when passing readonly colors, and include array size.
2012-04-04 01:02:15 +00:00
linearrgb_to_srgb_v3_v3(rgb_gamma, rgba);
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 [#22278] Colour Balance Node HSV Value slider range is insufficient.
2010-05-24 02:05:23 +00:00
RNA_property_float_ui_range(ptr, prop, &min, &max, &step, &precision);
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_CIRCLE:
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
circle_picker(block, ptr, prop);
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_SV:
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
square_picker(block, ptr, prop, UI_GRAD_SV);
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:
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
square_picker(block, ptr, prop, UI_GRAD_HS);
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:
rna/ui: avoid duplicate property gHash lookups by passing the property when its already been found. added _prop suffix to ui functions which take a prop rather then a propname, may change this later since its not that nice but for gsoc branches this keeps existing UI functions working the same.
2011-08-06 16:00:00 +00:00
square_picker(block, ptr, prop, UI_GRAD_HV);
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;
}
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 */
uiBlockBeginAlign(block);
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
bt = uiDefButS(block, ROW, 0, IFACE_("RGB"), 0, -30, width / 3, UI_UNIT_Y, &colormode, 0.0, 0.0, 0, 0, "");
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
uiButSetFunc(bt, do_picker_new_mode_cb, bt, NULL);
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
bt = uiDefButS(block, ROW, 0, IFACE_("HSV"), width / 3, -30, width / 3, UI_UNIT_Y, &colormode, 0.0, 1.0, 0, 0, "");
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
uiButSetFunc(bt, do_picker_new_mode_cb, bt, NULL);
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
bt = uiDefButS(block, ROW, 0, IFACE_("Hex"), 2 * width / 3, -30, width / 3, UI_UNIT_Y, &colormode, 0.0, 2.0, 0, 0, "");
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
uiButSetFunc(bt, do_picker_new_mode_cb, bt, NULL);
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
uiBlockEndAlign(block);
style cleanup: interface
2012-03-30 01:51:25 +00:00
bt = uiDefIconButO(block, BUT, "UI_OT_eyedropper", WM_OP_INVOKE_DEFAULT, ICON_EYEDROPPER, butwidth + 10, -60, UI_UNIT_X, UI_UNIT_Y, NULL);
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
uiButSetFunc(bt, close_popup_cb, bt, NULL);
/* RGB values */
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
uiBlockBeginAlign(block);
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
bt = uiDefButR_prop(block, NUMSLI, 0, IFACE_("R "), 0, -60, butwidth, UI_UNIT_Y, ptr, prop, 0, 0.0, 0.0, 0, 3, TIP_("Red"));
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
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
bt = uiDefButR_prop(block, NUMSLI, 0, IFACE_("G "), 0, -80, butwidth, UI_UNIT_Y, ptr, prop, 1, 0.0, 0.0, 0, 3, TIP_("Green"));
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
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
bt = uiDefButR_prop(block, NUMSLI, 0, IFACE_("B "), 0, -100, butwidth, UI_UNIT_Y, ptr, prop, 2, 0.0, 0.0, 0, 3, TIP_("Blue"));
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
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
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);
* but need to use uiButSetFunc 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 */
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
uiBlockBeginAlign(block);
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
bt = uiDefButF(block, NUMSLI, 0, IFACE_("H "), 0, -60, butwidth, UI_UNIT_Y, hsv, 0.0, 1.0, 10, 3, TIP_("Hue"));
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
uiButSetFunc(bt, do_hsv_rna_cb, bt, hsv);
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
bt = uiDefButF(block, NUMSLI, 0, IFACE_("S "), 0, -80, butwidth, UI_UNIT_Y, hsv + 1, 0.0, 1.0, 10, 3, TIP_("Saturation"));
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
uiButSetFunc(bt, do_hsv_rna_cb, bt, hsv);
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
bt = uiDefButF(block, NUMSLI, 0, IFACE_("V "), 0, -100, butwidth, UI_UNIT_Y, hsv + 2, 0.0, max, 10, 3, TIP_("Value"));
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
uiButSetFunc(bt, do_hsv_rna_cb, bt, hsv);
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
uiBlockEndAlign(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) {
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
bt = uiDefButR_prop(block, NUMSLI, 0, IFACE_("A "), 0, -120, butwidth, UI_UNIT_Y, ptr, prop, 3, 0.0, 0.0, 0, 0, TIP_("Alpha"));
alpha drawing for color picker, move alpha button into the picker.
2010-06-26 17:12:55 +00:00
uiButSetFunc(bt, do_picker_rna_cb, bt, NULL);
}
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
}
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_snprintf(hexcol, sizeof(hexcol), "%02X%02X%02X", FTOCHAR(rgb_gamma[0]), FTOCHAR(rgb_gamma[1]), FTOCHAR(rgb_gamma[2]));
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
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
bt = uiDefBut(block, TEX, 0, IFACE_("Hex: "), 0, -60, butwidth, UI_UNIT_Y, hexcol, 0, 8, 0, 0, TIP_("Hex triplet for color (#RRGGBB)"));
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
uiButSetFunc(bt, do_hex_rna_cb, bt, hexcol);
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
uiDefBut(block, LABEL, 0, IFACE_("(Gamma Corrected)"), 0, -80, 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
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(rgba, hsv);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +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
picker_new_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
- 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 int ui_picker_small_wheel_cb(const bContext *UNUSED(C), uiBlock *block, 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) {
if (but->type == HSVCUBE && but->active == NULL) {
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];
style cleanup: interface
2012-03-30 01:51:25 +00:00
float *hsv = ui_block_hsv_get(block);
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
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
ui_get_but_vectorf(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
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_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);
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(hsv, 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
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
ui_set_but_vectorf(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
add vector versions of hsv_to_rgb, rgb_to_hsv & rgb_to_hsv_compat
2012-05-26 11:01:01 +00:00
ui_update_block_buts_rgb(block, rgb);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
block = uiBeginBlock(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
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
if (but->rnaprop) {
if (RNA_property_subtype(but->rnaprop) == PROP_COLOR_GAMMA) {
block->color_profile = BLI_PR_NONE;
}
}
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
uiBlockSetFlag(block, UI_BLOCK_MOVEMOUSE_QUIT);
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
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
uiBlockPicker(block, handle->retvec, &but->rnapoin, but->rnaprop);
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->flag = UI_BLOCK_LOOP | UI_BLOCK_REDRAW | UI_BLOCK_KEEP_OPEN | UI_BLOCK_OUT_1;
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
uiBoundsBlock(block, 10);
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
block->block_event_func = ui_picker_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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->direction = UI_TOP;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
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
static int ui_popup_string_hash(char *str)
{
/* sometimes button contains hotkey, sometimes not, strip for proper compare */
int hash;
style cleanup: interface
2012-03-30 01:51:25 +00:00
char *delimit = strchr(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
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (delimit) *delimit = 0;
hash = BLI_ghashutil_strhash(str);
if (delimit) *delimit = '|';
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;
}
replace strnlen with BLI_strnlen, make some args const - no functional changes.
2011-09-26 17:30:56 +00:00
static 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 */
uiBut *ui_popup_menu_memory(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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
static int mem[256], first = 1;
int hash = block->puphash;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
mem[hash & 255] = 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)
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 (ui_popup_string_hash(but->str) == mem[hash & 255])
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
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
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
int mx, my, popup, slideout;
int startx, starty, maxrow;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
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 #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
int offset[2], direction, minwidth, width, height, 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: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
minwidth = BLI_RCT_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
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->type == PULLDOWN || pup->but->menu_create_func) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
direction = UI_DOWN;
flip = 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
}
else {
style cleanup: interface
2012-03-30 01:51:25 +00:00
direction = UI_TOP;
flip = 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
}
}
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;
direction = UI_DOWN;
flip = 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
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)
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
uiBlockSetRegion(block, handle->region);
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
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
uiBlockLayoutResolve(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
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
uiBlockSetFlag(block, UI_BLOCK_MOVEMOUSE_QUIT);
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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiBlockSetFlag(block, UI_BLOCK_LOOP | UI_BLOCK_REDRAW | UI_BLOCK_NUMSELECT | UI_BLOCK_RET_1);
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
uiBlockSetDirection(block, direction);
/* 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) &&
style cleanup: interface
2012-03-30 01:51:25 +00:00
(bt = ui_popup_menu_memory(block, NULL)))
{
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: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
offset[0] = -(bt->rect.xmin + 0.8f * BLI_RCT_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 #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)
code cleanup: use rect size macros for the interface
2012-08-21 19:35:06 +00:00
offset[0] = mini(offset[0], -(bt->rect.xmin + 0.8f * BLI_RCT_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
style cleanup: interface
2012-03-30 01:51:25 +00:00
offset[1] = 1.5 * UI_UNIT_Y;
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;
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
uiMenuPopupBoundsBlock(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) {
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
uiBlockSetDirection(block, UI_TOP);
uiBlockFlipOrder(block);
}
}
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
block->minbounds = minwidth;
Fix #19389: add lamp had no submenu to choose the type.
2009-09-21 10:54:15 +00:00
uiTextBoundsBlock(block, 50);
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)
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
uiBlockSetDirection(block, UI_RIGHT);
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
uiEndBlock(C, 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
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
}
style cleanup: line length and ensure some macros error when not ending with ';'
2012-05-17 07:59:25 +00:00
uiPopupBlockHandle *ui_popup_menu_create(bContext *C, ARegion *butregion, uiBut *but,
uiMenuCreateFunc menu_func, void *arg, char *str)
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);
uiStyle *style = UI_GetStyle();
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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup = MEM_callocN(sizeof(uiPopupMenu), __func__);
pup->block = uiBeginBlock(C, NULL, __func__, UI_EMBOSSP);
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 */
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->layout = uiBlockLayout(pup->block, UI_LAYOUT_VERTICAL, UI_LAYOUT_MENU, 0, 0, 200, 0, style);
pup->slideout = (but && (but->block->flag & UI_BLOCK_LOOP));
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;
pup->popup = 1;
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
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) {
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
/* menu is created from a string */
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->menu_func = ui_block_func_MENUSTR;
pup->menu_arg = 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
}
else {
/* menu is created from a callback */
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->menu_func = menu_func;
pup->menu_arg = arg;
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: 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) {
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle->popup = 1;
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: Handlers are now evaluated in a different order, fixing some issues like Shift+R (repeat last) not giving capital R in the text editor. There is also new modal handler list at the window level, and the API call will always add it to that one now, since modal handlers were not used in other levels. The order used to be: * window modal + keymap * area modal + keymap * region modal + keymap Now it is: * window modal * region keymap * area keymap * window keymap
2009-09-18 12:43:36 +00:00
UI_add_popup_handlers(C, &window->modalhandlers, 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
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: 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
uiPopupMenu *uiPupMenuBegin(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
{
style cleanup: interface
2012-03-30 01:51:25 +00:00
uiStyle *style = UI_GetStyle();
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;
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
pup->block = uiBeginBlock(C, NULL, __func__, UI_EMBOSSP);
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->block->flag |= UI_BLOCK_POPUP_MEMORY;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->block->puphash = ui_popup_menu_hash(title);
change to auto-opening menus so the first menu item in popup menu wont auto open. This way we can do predictable key-shortcut-chaining. Eg. Shift+A, M, O --- adds a metaball cone. In editmode Ctrl+V, X, A --- Assign new vertex group.
2012-09-10 10:50:08 +00:00
pup->block->auto_is_first_event = TRUE;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->layout = uiBlockLayout(pup->block, UI_LAYOUT_VERTICAL, UI_LAYOUT_MENU, 0, 0, 200, 0, style);
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 */
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 (title && 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);
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
uiDefIconTextBut(pup->block, 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 {
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
but = uiDefBut(pup->block, LABEL, 0, title, 0, 0, 200, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0, "");
style cleanup: interface
2012-03-30 01:51:25 +00:00
but->flag = UI_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 * 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 * 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
void uiPupMenuEnd(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;
style cleanup: interface
2012-03-30 01:51:25 +00:00
pup->popup = 1;
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);
menu->popup = 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
2.5: Handlers are now evaluated in a different order, fixing some issues like Shift+R (repeat last) not giving capital R in the text editor. There is also new modal handler list at the window level, and the API call will always add it to that one now, since modal handlers were not used in other levels. The order used to be: * window modal + keymap * area modal + keymap * region modal + keymap Now it is: * window modal * region keymap * area keymap * window keymap
2009-09-18 12:43:36 +00:00
UI_add_popup_handlers(C, &window->modalhandlers, menu);
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);
}
uiLayout *uiPupMenuLayout(uiPopupMenu *pup)
{
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
}
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
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
static void operator_name_cb(bContext *C, void *arg, int retval)
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
const char *opname = 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: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (opname && retval > 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_operator_name_call(C, opname, WM_OP_EXEC_DEFAULT, NULL);
}
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
static void operator_cb(bContext *C, void *arg, int retval)
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
wmOperator *op = arg;
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15: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 (op && retval > 0)
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
WM_operator_call(C, op);
else
WM_operator_free(op);
}
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 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
static void confirm_cancel_operator(void *opv)
{
WM_operator_free(opv);
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
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
static void vconfirm_opname(bContext *C, const char *opname, const char *title, const char *itemfmt, va_list ap)
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
{
uiPopupBlockHandle *handle;
char *s, buf[512];
style cleanup: interface
2012-03-30 01:51:25 +00:00
s = buf;
if (title) s += sprintf(s, "%s%%t|", title);
fix for more warnings. - modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array. - use BLI_snprintf rather then sprintf where the size of the string is known. - particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
2011-02-12 16:54:24 +00:00
vsnprintf(s, sizeof(buf) - (s - buf), itemfmt, ap);
style cleanup: interface
2012-03-30 01:51:25 +00:00
buf[sizeof(buf) - 1] = '\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
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = ui_popup_menu_create(C, NULL, NULL, NULL, NULL, buf);
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
handle->popup_func = operator_name_cb;
handle->popup_arg = (void *)opname;
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
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
static void confirm_operator(bContext *C, wmOperator *op, const char *title, const char *item)
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
{
uiPopupBlockHandle *handle;
char *s, buf[512];
style cleanup: interface
2012-03-30 01:51:25 +00:00
s = buf;
if (title) s += BLI_snprintf(s, sizeof(buf), "%s%%t|%s", title, item);
quiet some clang warnings & fix for bugs in exceptional cases. - ghost C api, BLI_get_folder_version() could assign garbage values. - pointcache ptcache_find_frames_around() had a superfluous NULL check which would have crashed anyway if actually NULL.
2011-04-23 12:57:03 +00:00
(void)s;
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
style cleanup: interface
2012-03-30 01:51:25 +00:00
handle = ui_popup_menu_create(C, NULL, NULL, NULL, NULL, buf);
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
handle->popup_func = operator_cb;
handle->popup_arg = op;
handle->cancel_func = confirm_cancel_operator;
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
void uiPupMenuOkee(bContext *C, const char *opname, const char *str, ...)
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
{
va_list ap;
char titlestr[256];
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_snprintf(titlestr, sizeof(titlestr), "OK? %%i%d", ICON_QUESTION);
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
va_start(ap, str);
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
vconfirm_opname(C, opname, titlestr, str, ap);
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
va_end(ap);
}
fix [#29537] file/save crashes when target path isnt found bug was that uiPupMenuSaveOver(...) could run the WM API call function which freed the operator, within the low level invoke function which kept using the freed memory. Changed uiPupMenuSaveOver(...) to only show a popup so the caller needs to check if the file exists and should be immediately written (which was done everywhere except for blend saving anyway). * added note that operators invoke/exec funcs cant call WM_operator_call(...) on themselves, ends up using freed memory. * added BLI_is_file(path), checks the file exists and isnt a directory.
2011-12-12 18:06:36 +00:00
/* note, only call this is the file exists,
* the case where the file does not exist so can be saved without a
* popup must be checked for already, since saving from here
* will free the operator which will break invoke().
* The operator state for this is implicitly OPERATOR_RUNNING_MODAL */
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
void uiPupMenuSaveOver(bContext *C, wmOperator *op, const char *filename)
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: whitespace, also add '?' to save over popup since it wasnt totally clear it was a question (user pointed this out, they thought it was just notification and lost their work).
2012-07-31 23:06:12 +00:00
confirm_operator(C, op, "Save Over?", filename);
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
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
void uiPupMenuNotice(bContext *C, const char *str, ...)
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
{
va_list ap;
va_start(ap, str);
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
vconfirm_opname(C, NULL, NULL, str, ap);
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
va_end(ap);
}
Enabled GCC -Wwrite-strings warning for CMake and replaced many 'char's for 'const char's,. Only one functional change where Transform orientations passed "" to BIF_createTransformOrientation() which could then have the value written into.
2010-12-03 17:05:21 +00:00
void uiPupMenuError(bContext *C, const char *str, ...)
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
{
va_list ap;
char nfmt[256];
char titlestr[256];
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_snprintf(titlestr, sizeof(titlestr), "Error %%i%d", ICON_ERROR);
2.5: UI & Menus * Cleaned up UI_interface.h a bit, and added some comments to organize things a bit and indicate what should be used when. * uiMenu* functions can now be used to create menus for headers too, this is done with a uiDefMenuBut, which takes a pointer to a uiMenuCreateFunc, that will then call uiMenu* functions. * Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are specific to making popup menus. Will convert the other conformation popup menu functions to use this too so we can remove some code. * Extended uiMenu functions, now there is is also: BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator. * Converted image window headers to use uiMenu functions, simplifies menu code further here. Did not remove the uiDefMenu functions as they are used in sequencer/view3d in some places now (will fix). * Also tried to simplify and fix bounds computation a bit better for popup menus. It tried to find out in advance what the size of the menu was but this is difficult with keymap strings in there, now uiPopupBoundsBlock can figure this out afterwards and ensure the popup is within the window bounds. Will convert some other functions to use this too.
2009-01-30 12:18:08 +00:00
use BLI_snprintf rather than sprintf for interface functions
2011-09-26 16:53:04 +00:00
BLI_strncpy(nfmt, str, sizeof(nfmt));
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
va_start(ap, str);
2.5 Added CTRL+W save Blender file. It's the first user of the uiPupMenuSaveOver() function, which I've recoded to accept an operator pointer. This is required because the operator property 'filename' has to be set to work. Other 'save over' users will require running operators too I guess.
2009-02-08 19:15:59 +00:00
vconfirm_opname(C, NULL, titlestr, nfmt, ap);
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
va_end(ap);
}
void uiPupMenuReports(bContext *C, ReportList *reports)
{
Report *report;
DynStr *ds;
char *str;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!reports || !reports->list.first)
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: 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
ds = BLI_dynstr_new();
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
for (report = reports->list.first; report; report = report->next) {
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 (report->type < reports->printlevel)
style cleanup: interface
2012-03-30 01:51:25 +00:00
; /* pass */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (report->type >= RPT_ERROR)
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
BLI_dynstr_appendf(ds, "Error %%i%d%%t|%s", ICON_ERROR, report->message);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (report->type >= RPT_WARNING)
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
BLI_dynstr_appendf(ds, "Warning %%i%d%%t|%s", ICON_ERROR, report->message);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (report->type >= RPT_INFO)
Info Header: Non-blocking Info Messages Reports (i.e. 'info' or 'errors') are now shown in the info header in place of the scene statistics if the last executed operator had some, with this info disappearing again once another operator is run (to show scene statistics again). For example, this means that info such as the the number of verts merged, or whether a Keying Set successfully inserted keyframes, etc. is now shown again somewhere, and that this is done in a non-blocking manner. The current implementation is still a bit crude (i.e. lacking fancy polish), but is at least barebones functional. The todos... * When more than 1 report message is generated by the last operator, there is currently a display of the number of reports. In future, it would be nice to be able to add a button beside this or make the label clickable with appropriate text indicating this (commented out atm) to show popup menu of all the reports... * There could probably be some kind of coloured backdrop behind the text. Currently using standard box, but that has padding problems, and lacks visual interest. * Timer based fade out/disappear?
2010-03-02 11:48:40 +00:00
BLI_dynstr_appendf(ds, "Info %%i%d%%t|%s", ICON_INFO, report->message);
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
str = BLI_dynstr_get_cstring(ds);
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] != '\0')
bugfix [#20736] crash if lasso select while invisble object is selected - also dont display empty menu's
2010-01-19 16:38:48 +00:00
ui_popup_menu_create(C, NULL, NULL, NULL, NULL, str);
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
MEM_freeN(str);
BLI_dynstr_free(ds);
}
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
menus are now global (like operators), so for eg, the info add menu and the 3D add menu can be shared.
2009-10-08 19:06:32 +00:00
void uiPupMenuInvoke(bContext *C, const char *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
{
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;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +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 changes to interface code (no functional changes) - made 2 loops on menu items break out of the loop when the item is found. - include function names in error prints.
2011-09-27 17:04:38 +00:00
printf("%s: named menu \"%s\" not found\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
return;
}
style cleanup: interface
2012-03-30 01:51:25 +00:00
if (mt->poll && mt->poll(C, mt) == 0)
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
return;
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
pup = uiPupMenuBegin(C, IFACE_(mt->label), ICON_NONE);
style cleanup: interface
2012-03-30 01:51:25 +00:00
layout = uiPupMenuLayout(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
mt->draw(C, &menu);
uiPupMenuEnd(C, pup);
}
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 **************************/
use 'const char *' by default with RNA functions except when the value is flagged as PROP_THICK_WRAP. Also use const char in many other parts of blenders code. Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
2010-11-17 09:45:45 +00:00
void uiPupBlockO(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);
handle->popup = 1;
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
2.5: Handlers are now evaluated in a different order, fixing some issues like Shift+R (repeat last) not giving capital R in the text editor. There is also new modal handler list at the window level, and the API call will always add it to that one now, since modal handlers were not used in other levels. The order used to be: * window modal + keymap * area modal + keymap * region modal + keymap Now it is: * window modal * region keymap * area keymap * window keymap
2009-09-18 12:43:36 +00:00
UI_add_popup_handlers(C, &window->modalhandlers, handle);
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);
}
void uiPupBlock(bContext *C, uiBlockCreateFunc func, void *arg)
{
uiPupBlockO(C, func, arg, NULL, 0);
}
Fix #29306: Alt+N, Enter In Image View Does closes the dialog without executing. If enter is pressed outside of any button in menu, generate two menu return values: - UI_RETURN_CANCEL so button wouldn't be executed - UI_RETURN_POPUP_OK so callback associated with popup block would be executed
2011-11-24 13:51:31 +00:00
void uiPupBlockEx(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);
handle->popup = 1;
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
UI_add_popup_handlers(C, &window->modalhandlers, handle);
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
2.5: Handlers are now evaluated in a different order, fixing some issues like Shift+R (repeat last) not giving capital R in the text editor. There is also new modal handler list at the window level, and the API call will always add it to that one now, since modal handlers were not used in other levels. The order used to be: * window modal + keymap * area modal + keymap * region modal + keymap Now it is: * window modal * region keymap * area keymap * window keymap
2009-09-18 12:43:36 +00:00
UI_add_popup_handlers(C, &window->modalhandlers, handle);
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
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
void uiPupBlockClose(bContext *C, uiBlock *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 (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
wmWindow *win = CTX_wm_window(C);
/* if loading new .blend while popup is open, window will be 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 (win) {
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_remove_popup_handlers(&win->modalhandlers, block->handle);
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
}
}
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
float *ui_block_hsv_get(uiBlock *block)
{
fix for crash in own recent color picker commit, store the hsv color in block->_hsv, which is only accessed via a function so it can be moved to a better place later. also fix cineon define for scons/cmake.
2010-10-14 11:33:51 +00:00
return block->_hsv;
bugfix [#23355] Square Color picker moving by itself and locking up
2010-10-13 13:53:49 +00:00
}
Copy Permalink