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

3600 lines
88 KiB
C
Raw Normal View History

Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/**
* $Id$
*
* ***** 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,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* The Original Code is Copyright (C) 2008 Blender Foundation.
* All rights reserved.
*
* Contributor(s): Blender Foundation
*
* ***** END GPL LICENSE BLOCK *****
*/
#include <math.h>
#include <stdlib.h>
#include <string.h>
#include "MEM_guardedalloc.h"
#include "DNA_color_types.h"
#include "DNA_object_types.h"
#include "DNA_screen_types.h"
#include "DNA_texture_types.h"
#include "DNA_userdef_types.h"
#include "DNA_windowmanager_types.h"
#include "BLI_arithb.h"
#include "BLI_blenlib.h"
#include "PIL_time.h"
#include "BKE_colortools.h"
#include "BKE_global.h"
#include "BKE_texture.h"
#include "BKE_utildefines.h"
#include "UI_interface.h"
#include "UI_text.h"
#include "interface.h"
#include "WM_api.h"
#include "WM_types.h"
/***************** structs and defines ****************/
#define BUTTON_TOOLTIP_DELAY 500
#define BUTTON_FLASH_DELAY 20
#define BUTTON_AUTO_OPEN_THRESH 0.3
#define BUTTON_MOUSE_TOWARDS_THRESH 1.0
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
typedef enum uiButtonActivateType {
BUTTON_ACTIVATE_OVER,
BUTTON_ACTIVATE,
BUTTON_ACTIVATE_APPLY,
BUTTON_ACTIVATE_TEXT_EDITING,
BUTTON_ACTIVATE_OPEN
} uiButtonActivateType;
typedef enum uiHandleButtonState {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
BUTTON_STATE_INIT,
BUTTON_STATE_HIGHLIGHT,
BUTTON_STATE_WAIT_FLASH,
BUTTON_STATE_WAIT_RELEASE,
BUTTON_STATE_WAIT_KEY_EVENT,
BUTTON_STATE_NUM_EDITING,
BUTTON_STATE_TEXT_EDITING,
BUTTON_STATE_TEXT_SELECTING,
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
BUTTON_STATE_MENU_OPEN,
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
BUTTON_STATE_EXIT
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
} uiHandleButtonState;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
typedef struct uiHandleMenuData {
uiMenuBlockHandle *handle;
int towardsx, towardsy;
double towardstime;
int dotowards;
} uiHandleMenuData;
typedef struct uiHandleButtonData {
wmWindow *window;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 *region;
int interactive;
/* overall state */
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
uiHandleButtonState state;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
int cancel, retval;
int applied, appliedinteractive;
wmTimerHandle *flashtimer;
/* edited value */
char *str, *origstr;
double value, origvalue;
float vec[3], origvec[3];
int togdual, togonly;
ColorBand *coba;
CurveMapping *cumap;
/* tooltip */
ARegion *tooltip;
wmTimerHandle *tooltiptimer;
wmTimerHandle *autoopentimer;
/* text selection/editing */
int maxlen, selextend, selstartx;
/* number editing / dragging */
int draglastx, draglasty;
int dragstartx, dragstarty;
int dragchange, draglock, dragsel;
float dragf, dragfstart;
CBData *dragcbd;
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
/* menu open */
uiHandleMenuData *menu;
int menuretval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* post activate */
uiButtonActivateType posttype;
uiBut *postbut;
} uiHandleButtonData;
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
typedef struct uiAfterFunc {
struct uiAfterFunc *next, *prev;
void (*func)(struct bContext*, void *, void *);
void *func_arg1;
void *func_arg2;
void (*handle_func)(struct bContext*, void *arg, int event);
void *handle_func_arg;
int retval;
void (*butm_func)(struct bContext*, void *arg, int event);
void *butm_func_arg;
int a2;
} uiAfterFunc;
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
static void button_activate_state(bContext *C, uiBut *but, uiHandleButtonState state);
static int ui_handler_window(bContext *C, wmEvent *event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
/* ********************** button apply/revert ************************/
static ListBase UIAfterFuncs = {NULL, 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
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_func(bContext *C, uiBut *but)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
uiAfterFunc *after;
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
uiBlock *block= but->block;
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
/* these functions are postponed and only executed after all other
* handling is done, i.e. menus are closed, in order to avoid conflicts
* with these functions removing the buttons we are working with */
if(but->func || block->handle_func || (but->type == BUTM && block->butm_func)) {
after= MEM_callocN(sizeof(uiAfterFunc), "uiAfterFunc");
after->func= but->func;
after->func_arg1= but->func_arg1;
after->func_arg2= but->func_arg2;
after->handle_func= block->handle_func;
after->handle_func_arg= block->handle_func_arg;
after->retval= but->retval;
if(but->type == BUTM) {
after->butm_func= block->butm_func;
after->butm_func_arg= block->butm_func_arg;
after->a2= but->a2;
}
BLI_addtail(&UIAfterFuncs, after);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
static void ui_apply_but_funcs_after(bContext *C)
{
uiAfterFunc *after;
for(after=UIAfterFuncs.first; after; after=after->next) {
if(after->func)
after->func(C, after->func_arg1, after->func_arg2);
if(after->handle_func)
after->handle_func(C, after->handle_func_arg, after->retval);
if(after->butm_func)
after->butm_func(C, after->butm_func_arg, after->a2);
}
BLI_freelistN(&UIAfterFuncs);
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_BUT(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_BUTM(bContext *C, uiBut *but, uiHandleButtonData *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
{
ui_set_but_val(but, but->min);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_BLOCK(bContext *C, uiBut *but, uiHandleButtonData *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
{
if(but->type == COL)
ui_set_but_vectorf(but, data->vec);
else if(ELEM3(but->type, MENU, ICONROW, ICONTEXTROW))
ui_set_but_val(but, data->value);
ui_check_but(but);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_TOG(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *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
{
double value;
int w, lvalue, push;
/* local hack... */
if(but->type==BUT_TOGDUAL && data->togdual) {
if(but->pointype==SHO)
but->poin += 2;
else if(but->pointype==INT)
but->poin += 4;
}
value= ui_get_but_val(but);
lvalue= (int)value;
if(but->bit) {
w= BTST(lvalue, but->bitnr);
if(w) lvalue = BCLR(lvalue, but->bitnr);
else lvalue = BSET(lvalue, but->bitnr);
if(but->type==TOGR) {
if(!data->togonly) {
lvalue= 1<<(but->bitnr);
ui_set_but_val(but, (double)lvalue);
}
else {
if(lvalue==0) lvalue= 1<<(but->bitnr);
}
}
ui_set_but_val(but, (double)lvalue);
if(but->type==ICONTOG || but->type==ICONTOGN) ui_check_but(but);
}
else {
if(value==0.0) push= 1;
else push= 0;
if(but->type==TOGN || but->type==ICONTOGN) push= !push;
ui_set_but_val(but, (double)push);
if(but->type==ICONTOG || but->type==ICONTOGN) ui_check_but(but);
}
/* end local hack... */
if(but->type==BUT_TOGDUAL && data->togdual) {
if(but->pointype==SHO)
but->poin -= 2;
else if(but->pointype==INT)
but->poin -= 4;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_ROW(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *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
{
ui_set_but_val(but, but->max);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_TEX(bContext *C, uiBut *but, uiHandleButtonData *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
{
if(!data->str)
return;
ui_set_but_string(but, data->str);
ui_check_but(but);
/* give butfunc the original text too */
/* feature used for bone renaming, channels, etc */
if(but->func_arg2==NULL) but->func_arg2= data->origstr;
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(but->func_arg2==data->origstr) but->func_arg2= NULL;
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_NUM(bContext *C, uiBut *but, uiHandleButtonData *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
{
if(data->str) {
/* XXX 2.50 missing python api */
#if 0
if(BPY_button_eval(data->str, &data->value)) {
WM_report(C, WM_LOG_WARNING, "Invalid Python expression, check console");
data->value = 0.0f; /* Zero out value on error */
if(data->str[0]) {
data->cancel= 1; /* invalidate return value if eval failed, except when string was null */
return;
}
}
#else
data->value= atof(data->str);
#endif
if(!ui_is_but_float(but)) data->value= (int)data->value;
if(but->type==NUMABS) data->value= fabs(data->value);
if(data->value<but->min) data->value= but->min;
if(data->value>but->max) data->value= but->max;
}
ui_set_but_val(but, data->value);
ui_check_but(but);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_LABEL(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_TOG3(bContext *C, uiBut *but, uiHandleButtonData *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
{
if(but->pointype==SHO ) {
short *sp= (short *)but->poin;
if( BTST(sp[1], but->bitnr)) {
sp[1]= BCLR(sp[1], but->bitnr);
sp[0]= BCLR(sp[0], but->bitnr);
}
else if( BTST(sp[0], but->bitnr)) {
sp[1]= BSET(sp[1], but->bitnr);
} else {
sp[0]= BSET(sp[0], but->bitnr);
}
}
else {
if( BTST(*(but->poin+2), but->bitnr)) {
*(but->poin+2)= BCLR(*(but->poin+2), but->bitnr);
*(but->poin)= BCLR(*(but->poin), but->bitnr);
}
else if( BTST(*(but->poin), but->bitnr)) {
*(but->poin+2)= BSET(*(but->poin+2), but->bitnr);
} else {
*(but->poin)= BSET(*(but->poin), but->bitnr);
}
}
ui_check_but(but);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_VEC(bContext *C, uiBut *but, uiHandleButtonData *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
{
ui_set_but_vectorf(but, data->vec);
ui_check_but(but);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_COLORBAND(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_CURVE(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_IDPOIN(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
but->idpoin_func(C, data->str, but->idpoin_idpp);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(but);
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
#ifdef INTERNATIONAL
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_but_CHARTAB(bContext *C, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_func(C, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->retval= but->retval;
data->applied= 1;
}
#endif
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static void ui_apply_button(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, int interactive)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *editstr;
double *editval;
float *editvec;
ColorBand *editcoba;
CurveMapping *editcumap;
data->retval= 0;
/* if we cancel and have not applied yet, there is nothing to do,
* otherwise we have to restore the original value again */
if(data->cancel) {
if(!data->applied)
return;
if(data->str) MEM_freeN(data->str);
data->str= data->origstr;
data->origstr= NULL;
data->value= data->origvalue;
data->origvalue= 0.0;
VECCOPY(data->vec, data->origvec);
data->origvec[0]= data->origvec[1]= data->origvec[2]= 0.0f;
}
else {
/* we avoid applying interactive edits a second time
* at the end with the appliedinteractive flag */
if(interactive)
data->appliedinteractive= 1;
else if(data->appliedinteractive)
return;
}
/* ensures we are writing actual values */
editstr= but->editstr;
editval= but->editval;
editvec= but->editvec;
editcoba= but->editcoba;
editcumap= but->editcumap;
but->editstr= NULL;
but->editval= NULL;
but->editvec= NULL;
but->editcoba= NULL;
but->editcumap= NULL;
/* handle different types */
switch(but->type) {
case BUT:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_BUT(C, but, 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
break;
case TEX:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_TEX(C, but, 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
break;
case TOG:
case TOGR:
case ICONTOG:
case ICONTOGN:
case TOGN:
case BUT_TOGDUAL:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_TOG(C, block, but, 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
break;
case ROW:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_ROW(C, block, but, 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
break;
case SCROLL:
break;
case NUM:
case NUMABS:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_NUM(C, but, 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
break;
case SLI:
case NUMSLI:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_NUM(C, but, 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
break;
case HSVSLI:
break;
case ROUNDBOX:
case LABEL:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_LABEL(C, but, 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
break;
case TOG3:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_TOG3(C, but, 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
break;
case MENU:
case ICONROW:
case ICONTEXTROW:
case BLOCK:
case PULLDOWN:
case COL:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_BLOCK(C, but, 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
break;
case BUTM:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_BUTM(C, but, 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
break;
case BUT_NORMAL:
case HSVCUBE:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_VEC(C, but, 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
break;
case BUT_COLORBAND:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_COLORBAND(C, but, 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
break;
case BUT_CURVE:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_CURVE(C, but, 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
break;
case IDPOIN:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_IDPOIN(C, but, 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
break;
#ifdef INTERNATIONAL
case CHARTAB:
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_but_CHARTAB(C, but, 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
break;
#endif
case LINK:
case INLINK:
break;
}
but->editstr= editstr;
but->editval= editval;
but->editvec= editvec;
but->editcoba= editcoba;
but->editcumap= editcumap;
}
/* ******************* copy and paste ******************** */
/* c = copy, v = paste */
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
static void ui_but_copy_paste(bContext *C, uiBut *but, uiHandleButtonData *data, char mode)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
static ColorBand but_copypaste_coba = {0};
char buf[UI_MAX_DRAW_STR+1]= {0};
double val;
if(mode=='v' && but->lock)
return;
if(mode=='v') {
/* extract first line from clipboard in case of multi-line copies */
char *p = NULL; /* XXX 2.48 getClipboard(0); */
if(p) {
int i = 0;
while (*p && *p!='\r' && *p!='\n' && i<UI_MAX_DRAW_STR) {
buf[i++]=*p;
p++;
}
buf[i]= 0;
}
}
/* numeric value */
if ELEM4(but->type, NUM, NUMABS, NUMSLI, HSVSLI) {
if(but->poin==NULL && but->rnapoin.data==NULL);
else if(mode=='c') {
sprintf(buf, "%f", ui_get_but_val(but));
/* XXX 2.48 putClipboard(buf, 0); */
}
else {
if (sscanf(buf, " %lf ", &val) == 1) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
data->value= val;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
}
}
/* RGB triple */
else if(but->type==COL) {
float rgb[3];
if(but->poin==NULL && but->rnapoin.data==NULL);
else if(mode=='c') {
ui_get_but_vectorf(but, rgb);
sprintf(buf, "[%f, %f, %f]", rgb[0], rgb[1], rgb[2]);
/* XXX 2.48 putClipboard(buf, 0); */
}
else {
if (sscanf(buf, "[%f, %f, %f]", &rgb[0], &rgb[1], &rgb[2]) == 3) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
VECCOPY(data->vec, rgb);
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
}
}
/* text/string and ID data */
else if(ELEM(but->type, TEX, IDPOIN)) {
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
uiHandleButtonData *data= but->active;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(but->poin==NULL && but->rnapoin.data==NULL);
else if(mode=='c') {
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
BLI_strncpy(buf, data->str, UI_MAX_DRAW_STR);
/* XXX 2.48 putClipboard(data->str, 0); */
data->cancel= 1;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else {
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
BLI_strncpy(data->str, buf, data->maxlen);
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
}
/* colorband (not supported by system clipboard) */
else if(but->type==BUT_COLORBAND) {
if(mode=='c') {
if(but->poin)
return;
memcpy(&but_copypaste_coba, but->poin, sizeof(ColorBand));
}
else {
if(but_copypaste_coba.tot==0)
return;
if(!but->poin)
but->poin= MEM_callocN(sizeof(ColorBand), "colorband");
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
memcpy(data->coba, &but_copypaste_coba, sizeof(ColorBand) );
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
}
}
/* ************* in-button text selection/editing ************* */
/* return 1 if char ch is special character, otherwise return 0 */
static short test_special_char(char ch)
{
switch(ch) {
case '\\':
case '/':
case '~':
case '!':
case '@':
case '#':
case '$':
case '%':
case '^':
case '&':
case '*':
case '(':
case ')':
case '+':
case '=':
case '{':
case '}':
case '[':
case ']':
case ':':
case ';':
case '\'':
case '\"':
case '<':
case '>':
case ',':
case '.':
case '?':
case '_':
case '-':
case ' ':
return 1;
break;
default:
break;
}
return 0;
}
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
static int ui_textedit_delete_selection(uiBut *but, uiHandleButtonData *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
{
char *str;
int x, changed;
str= data->str;
changed= (but->selsta != but->selend);
for(x=0; x< strlen(str); x++) {
if (but->selend + x <= strlen(str) ) {
str[but->selsta + x]= str[but->selend + x];
} else {
str[but->selsta + x]= '\0';
break;
}
}
but->pos = but->selend = but->selsta;
return changed;
}
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
static void ui_textedit_set_cursor_pos(uiBut *but, uiHandleButtonData *data, short x)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *origstr;
origstr= MEM_callocN(sizeof(char)*(data->maxlen+1), "ui_textedit origstr");
BLI_strncpy(origstr, but->drawstr, data->maxlen+1);
but->pos= strlen(origstr)-but->ofs;
while((but->aspect*UI_GetStringWidth(but->font, origstr+but->ofs, 0) + but->x1) > x) {
if (but->pos <= 0) break;
but->pos--;
origstr[but->pos+but->ofs] = 0;
}
but->pos -= strlen(but->str);
but->pos += but->ofs;
if(but->pos<0) but->pos= 0;
MEM_freeN(origstr);
}
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
static void ui_textedit_set_cursor_select(uiBut *but, uiHandleButtonData *data, short x)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 (x > data->selstartx) data->selextend = EXTEND_RIGHT;
else if (x < data->selstartx) data->selextend = EXTEND_LEFT;
ui_textedit_set_cursor_pos(but, data, x);
if (data->selextend == EXTEND_RIGHT) but->selend = but->pos;
if (data->selextend == EXTEND_LEFT) but->selsta = but->pos;
ui_check_but(but);
}
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
static int ui_textedit_type_ascii(uiBut *but, uiHandleButtonData *data, char ascii)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *str;
int len, x, changed= 0;
str= data->str;
len= strlen(str);
if(len-(but->selend - but->selsta)+1 <= data->maxlen) {
/* type over the current selection */
if ((but->selend - but->selsta) > 0)
changed= ui_textedit_delete_selection(but, data);
len= strlen(str);
if(len < data->maxlen) {
for(x= data->maxlen; x>but->pos; x--)
str[x]= str[x-1];
str[but->pos]= ascii;
str[len+1]= '\0';
but->pos++;
changed= 1;
}
}
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
void ui_textedit_move(uiBut *but, uiHandleButtonData *data, int direction, int select, int jump)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *str;
int len;
str= data->str;
len= strlen(str);
if(direction) { /* right*/
/* if there's a selection */
if ((but->selend - but->selsta) > 0) {
/* extend the selection based on the first direction taken */
if(select) {
if (!data->selextend) {
data->selextend = EXTEND_RIGHT;
}
if (data->selextend == EXTEND_RIGHT) {
but->selend++;
if (but->selend > len) but->selend = len;
} else if (data->selextend == EXTEND_LEFT) {
but->selsta++;
/* if the selection start has gone past the end,
* flip them so they're in sync again */
if (but->selsta == but->selend) {
but->pos = but->selsta;
data->selextend = EXTEND_RIGHT;
}
}
} else {
but->selsta = but->pos = but->selend;
data->selextend = 0;
}
} else {
if(select) {
/* make a selection, starting from the cursor position */
but->selsta = but->pos;
but->pos++;
if(but->pos>strlen(str)) but->pos= strlen(str);
but->selend = but->pos;
} else if(jump) {
/* jump betweenn special characters (/,\,_,-, etc.),
* look at function test_special_char() for complete
* list of special character, ctr -> */
while(but->pos < len) {
but->pos++;
if(test_special_char(str[but->pos])) break;
}
} else {
but->pos++;
if(but->pos>strlen(str)) but->pos= strlen(str);
}
}
}
else { /* left */
/* if there's a selection */
if ((but->selend - but->selsta) > 0) {
/* extend the selection based on the first direction taken */
if(select) {
if (!data->selextend) {
data->selextend = EXTEND_LEFT;
}
if (data->selextend == EXTEND_LEFT) {
but->selsta--;
if (but->selsta < 0) but->selsta = 0;
} else if (data->selextend == EXTEND_RIGHT) {
but->selend--;
/* if the selection start has gone past the end,
* flip them so they're in sync again */
if (but->selsta == but->selend) {
but->pos = but->selsta;
data->selextend = EXTEND_LEFT;
}
}
} else {
but->pos = but->selend = but->selsta;
data->selextend = 0;
}
} else {
if(select) {
/* make a selection, starting from the cursor position */
but->selend = but->pos;
but->pos--;
if(but->pos<0) but->pos= 0;
but->selsta = but->pos;
} else if(jump) {
/* jump betweenn special characters (/,\,_,-, etc.),
* look at function test_special_char() for complete
* list of special character, ctr -> */
while(but->pos > 0){
but->pos--;
if(test_special_char(str[but->pos])) break;
}
} else {
if(but->pos>0) but->pos--;
}
}
}
}
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
void ui_textedit_move_end(uiBut *but, uiHandleButtonData *data, int direction, int select)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *str;
str= data->str;
if(direction) { /* right */
if(select) {
but->selsta = but->pos;
but->selend = strlen(str);
data->selextend = EXTEND_RIGHT;
} else {
but->selsta = but->selend = but->pos= strlen(str);
}
}
else { /* left */
if(select) {
but->selend = but->pos;
but->selsta = 0;
data->selextend = EXTEND_LEFT;
} else {
but->selsta = but->selend = but->pos= 0;
}
}
}
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
static int ui_textedit_delete(uiBut *but, uiHandleButtonData *data, int direction, int all)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char *str;
int len, x, changed= 0;
str= data->str;
len= strlen(str);
if(all) {
if(len) changed=1;
str[0]= 0;
but->pos= 0;
}
else if(direction) { /* delete */
if ((but->selend - but->selsta) > 0) {
changed= ui_textedit_delete_selection(but, data);
}
else if(but->pos>=0 && but->pos<len) {
for(x=but->pos; x<len; x++)
str[x]= str[x+1];
str[len-1]='\0';
changed= 1;
}
}
else { /* backspace */
if(len!=0) {
if ((but->selend - but->selsta) > 0) {
ui_textedit_delete_selection(but, data);
}
else if(but->pos>0) {
for(x=but->pos; x<len; x++)
str[x-1]= str[x];
str[len-1]='\0';
but->pos--;
changed= 1;
}
}
}
return changed;
}
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
static int ui_textedit_autocomplete(bContext *C, uiBut *but, uiHandleButtonData *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
{
char *str;
int changed= 1;
str= data->str;
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
but->autocomplete_func(C, str, but->autofunc_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
but->pos= strlen(str);
return changed;
}
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
static int ui_textedit_copypaste(uiBut *but, uiHandleButtonData *data, int paste, int copy, int cut)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
char buf[UI_MAX_DRAW_STR]={0};
char *str, *p;
int len, x, y, i, changed= 0;
str= data->str;
len= strlen(str);
/* paste */
if (paste) {
/* extract the first line from the clipboard */
p = NULL; /* XXX 2.48 getClipboard(0); */
if(p && p[0]) {
while (*p && *p!='\r' && *p!='\n' && i<UI_MAX_DRAW_STR) {
buf[i++]=*p;
p++;
}
buf[i]= 0;
/* paste over the current selection */
if ((but->selend - but->selsta) > 0)
ui_textedit_delete_selection(but, data);
for (y=0; y<strlen(buf); y++)
{
/* add contents of buffer */
if(len < data->maxlen) {
for(x= data->maxlen; x>but->pos; x--)
str[x]= str[x-1];
str[but->pos]= buf[y];
but->pos++;
len++;
str[len]= '\0';
}
}
changed= 1;
}
}
/* cut & copy */
else if (copy || cut) {
/* copy the contents to the copypaste buffer */
for(x= but->selsta; x <= but->selend; x++) {
if (x==but->selend)
buf[x] = '\0';
else
buf[(x - but->selsta)] = str[x];
}
/* XXX 2.48 putClipboard(buf, 0); */
/* for cut only, delete the selection afterwards */
if(cut)
if((but->selend - but->selsta) > 0)
changed= ui_textedit_delete_selection(but, data);
}
return changed;
}
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
static void ui_textedit_begin(uiBut *but, uiHandleButtonData *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
{
if(data->str) {
MEM_freeN(data->str);
data->str= NULL;
}
/* retrieve string */
if(but->type == TEX) {
data->maxlen= but->max;
data->str= MEM_callocN(sizeof(char)*(data->maxlen+1), "textedit str");
ui_get_but_string(but, data->str, data->maxlen+1);
}
else if(but->type == IDPOIN) {
ID *id;
data->maxlen= 22;
data->str= MEM_callocN(sizeof(char)*(data->maxlen+1), "textedit str");
id= *but->idpoin_idpp;
if(id) BLI_strncpy(data->str, id->name+2, data->maxlen+1);
else data->str[0]= 0;
}
else {
double value;
data->maxlen= UI_MAX_DRAW_STR;
data->str= MEM_callocN(sizeof(char)*(data->maxlen+1), "textedit str");
value= ui_get_but_val(but);
if(ui_is_but_float(but)) {
if(but->a2) { /* amount of digits defined */
if(but->a2==1) sprintf(data->str, "%.1f", value);
else if(but->a2==2) sprintf(data->str, "%.2f", value);
else if(but->a2==3) sprintf(data->str, "%.3f", value);
else sprintf(data->str, "%.4f", value);
}
else sprintf(data->str, "%.3f", value);
}
else {
sprintf(data->str, "%d", (int)value);
}
}
data->origstr= BLI_strdup(data->str);
data->selextend= 0;
data->selstartx= 0;
/* set cursor pos to the end of the text */
but->editstr= data->str;
but->pos= strlen(data->str);
but->selsta= 0;
but->selend= strlen(but->drawstr) - strlen(but->str);
ui_check_but(but);
}
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
static void ui_textedit_end(uiBut *but, uiHandleButtonData *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
{
if(but) {
but->editstr= 0;
but->pos= -1;
}
}
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
static void ui_textedit_next_but(uiBlock *block, uiBut *actbut, uiHandleButtonData *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
{
uiBut *but;
/* label and roundbox can overlap real buttons (backdrops...) */
if(actbut->type==LABEL && actbut->type==ROUNDBOX)
return;
for(but= actbut->next; but; but= but->next) {
if(ELEM5(but->type, TEX, NUM, NUMABS, NUMSLI, HSVSLI)) {
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
data->postbut= but;
data->posttype= BUTTON_ACTIVATE_TEXT_EDITING;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
}
}
for(but= block->buttons.first; but!=actbut; but= but->next) {
if(ELEM5(but->type, TEX, NUM, NUMABS, NUMSLI, HSVSLI)) {
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
data->postbut= but;
data->posttype= BUTTON_ACTIVATE_TEXT_EDITING;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
}
}
}
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
static void ui_textedit_prev_but(uiBlock *block, uiBut *actbut, uiHandleButtonData *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
{
uiBut *but;
/* label and roundbox can overlap real buttons (backdrops...) */
if(actbut->type==LABEL && actbut->type==ROUNDBOX)
return;
for(but= actbut->prev; but; but= but->prev) {
if(ELEM5(but->type, TEX, NUM, NUMABS, NUMSLI, HSVSLI)) {
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
data->postbut= but;
data->posttype= BUTTON_ACTIVATE_TEXT_EDITING;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
}
}
for(but= block->buttons.last; but!=actbut; but= but->prev) {
if(ELEM5(but->type, TEX, NUM, NUMABS, NUMSLI, HSVSLI)) {
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
data->postbut= but;
data->posttype= BUTTON_ACTIVATE_TEXT_EDITING;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
}
}
}
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
static void ui_do_but_textedit(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
int mx, my, changed= 0, retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
switch(event->type) {
case RIGHTMOUSE:
case ESCKEY:
data->cancel= 1;
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case LEFTMOUSE: {
if(event->val) {
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if ((but->y1 <= my) && (my <= but->y2) && (but->x1 <= mx) && (mx <= but->x2)) {
ui_textedit_set_cursor_pos(but, data, mx);
but->selsta = but->selend = but->pos;
data->selstartx= mx;
button_activate_state(C, but, BUTTON_STATE_TEXT_SELECTING);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else {
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
break;
}
}
if(event->val) {
switch (event->type) {
case VKEY:
case XKEY:
case CKEY:
if(event->ctrl || event->oskey) {
if(event->type == VKEY)
changed= ui_textedit_copypaste(but, data, 1, 0, 0);
else if(event->type == XKEY)
changed= ui_textedit_copypaste(but, data, 0, 1, 0);
else if(event->type == CKEY)
changed= ui_textedit_copypaste(but, data, 0, 0, 1);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
break;
case RIGHTARROWKEY:
ui_textedit_move(but, data, 1, event->shift, event->ctrl);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case LEFTARROWKEY:
ui_textedit_move(but, data, 0, event->shift, event->ctrl);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case DOWNARROWKEY:
case ENDKEY:
ui_textedit_move_end(but, data, 1, event->shift);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case UPARROWKEY:
case HOMEKEY:
ui_textedit_move_end(but, data, 0, event->shift);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case PADENTER:
case RETKEY:
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case DELKEY:
changed= ui_textedit_delete(but, data, 1, 0);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BACKSPACEKEY:
changed= ui_textedit_delete(but, data, 0, event->shift);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case TABKEY:
/* there is a key conflict here, we can't tab with autocomplete */
if(but->autocomplete_func) {
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
changed= ui_textedit_autocomplete(C, but, data);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
/* the hotkey here is not well defined, was G.qual so we check all */
else if(event->shift || event->ctrl || event->alt || event->oskey) {
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_textedit_prev_but(block, but, 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
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else {
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_textedit_next_but(block, but, 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
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
}
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
if(event->ascii && (retval == WM_UI_HANDLER_CONTINUE)) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
changed= ui_textedit_type_ascii(but, data, event->ascii);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
if(changed) {
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
if(data->interactive) ui_apply_button(C, block, but, data, 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 ui_check_but(but);
}
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
if(changed || (retval == WM_UI_HANDLER_BREAK))
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
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
static void ui_do_but_textedit_select(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
int mx, my, retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
switch(event->type) {
case MOUSEMOVE: {
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
ui_textedit_set_cursor_select(but, data, mx);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
}
case LEFTMOUSE:
if(event->val == 0)
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
}
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
if(retval == WM_UI_HANDLER_BREAK) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
ui_check_but(but);
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
}
/* ************* number editing for various types ************* */
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
static void ui_numedit_begin(uiBut *but, uiHandleButtonData *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
{
float butrange;
if(but->type == BUT_CURVE) {
data->cumap= (CurveMapping*)but->poin;
but->editcumap= data->coba;
}
else if(but->type == BUT_COLORBAND) {
data->coba= (ColorBand*)but->poin;
but->editcoba= data->coba;
}
else if(ELEM(but->type, BUT_NORMAL, HSVCUBE)) {
ui_get_but_vectorf(but, data->origvec);
VECCOPY(data->vec, data->origvec);
but->editvec= data->vec;
}
else {
data->origvalue= ui_get_but_val(but);
data->value= data->origvalue;
but->editval= &data->value;
butrange= (but->max - but->min);
data->dragfstart= (butrange == 0.0)? 0.0f: (data->value - but->min)/butrange;
data->dragf= data->dragfstart;
}
data->dragchange= 0;
data->draglock= 1;
}
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
static void ui_numedit_end(uiBut *but, uiHandleButtonData *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
{
but->editval= NULL;
but->editvec= NULL;
but->editcoba= NULL;
but->editcumap= NULL;
data->dragstartx= 0;
data->draglastx= 0;
data->dragchange= 0;
data->dragcbd= NULL;
data->dragsel= 0;
}
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
static void ui_numedit_apply(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *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
{
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
if(data->interactive) ui_apply_button(C, block, but, data, 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 ui_check_but(but);
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
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
/* ****************** menu opening for various types **************** */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static void ui_blockopen_begin(bContext *C, uiBut *but, uiHandleButtonData *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
{
uiBlockFuncFP func= NULL;
void *arg= NULL;
switch(but->type) {
case BLOCK:
case PULLDOWN:
func= but->block_func;
arg= but->poin;
break;
case MENU:
data->origvalue= ui_get_but_val(but);
data->value= data->origvalue;
but->editval= &data->value;
func= ui_block_func_MENU;
arg= but;
break;
case ICONROW:
func= ui_block_func_ICONROW;
arg= but;
break;
case ICONTEXTROW:
func= ui_block_func_ICONTEXTROW;
arg= but;
break;
case COL:
ui_get_but_vectorf(but, data->origvec);
VECCOPY(data->vec, data->origvec);
but->editvec= data->vec;
func= ui_block_func_COL;
arg= but;
break;
}
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
if(func) {
data->menu= MEM_callocN(sizeof(uiHandleMenuData), "uiHandleMenuData");
data->menu->handle= ui_menu_block_create(C, data->region, but, func, 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
/* this makes adjacent blocks auto open from now on */
if(but->block->auto_open==0) but->block->auto_open= 1;
}
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
static void ui_blockopen_end(bContext *C, uiBut *but, uiHandleButtonData *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
{
if(but) {
but->editval= NULL;
but->editvec= NULL;
but->block->auto_open_last= PIL_check_seconds_timer();
}
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
if(data->menu) {
ui_menu_block_free(C, data->menu->handle);
MEM_freeN(data->menu);
data->menu= 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
}
}
/* ***************** events for different button types *************** */
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
static int ui_do_but_BUT(bContext *C, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(event->type == LEFTMOUSE && event->val) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_WAIT_RELEASE);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
else if(ELEM(event->type, PADENTER, RETKEY) && event->val) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_WAIT_FLASH);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(data->state == BUTTON_STATE_WAIT_RELEASE) {
if(event->type == LEFTMOUSE && event->val==0) {
if(!(but->flag & UI_SELECT))
data->cancel= 1;
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_do_but_KEYEVT(bContext *C, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_WAIT_KEY_EVENT);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(data->state == BUTTON_STATE_WAIT_KEY_EVENT) {
if(event->type == MOUSEMOVE)
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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 missing function */
#if 0
if(event->val) {
if(!key_event_to_string(event)[0])
data->cancel= 1;
else
ui_set_but_val(but, event->type);
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
#endif
}
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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_do_but_TEX(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
else if(data->state == BUTTON_STATE_TEXT_EDITING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit(C, block, but, data, event);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
else if(data->state == BUTTON_STATE_TEXT_SELECTING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit_select(C, block, but, data, event);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_do_but_TOG(bContext *C, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
data->togdual= event->ctrl;
data->togonly= !event->shift;
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_do_but_EXIT(bContext *C, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_numedit_but_NUM(uiBut *but, uiHandleButtonData *data, float fac, int snap, int mx)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
float deler, tempf;
int lvalue, temp, changed= 0;
if(mx == data->draglastx)
return changed;
/* drag-lock - prevent unwanted scroll adjustments */
/* change value (now 3) to adjust threshold in pixels */
if(data->draglock) {
if(abs(mx-data->dragstartx) <= 3)
return changed;
data->draglock= 0;
data->dragstartx= mx; /* ignore mouse movement within drag-lock */
}
deler= 500;
if(!ui_is_but_float(but)) {
if((but->max-but->min)<100) deler= 200.0;
if((but->max-but->min)<25) deler= 50.0;
}
deler /= fac;
if(ui_is_but_float(but) && but->max-but->min > 11) {
/* non linear change in mouse input- good for high precicsion */
data->dragf+= (((float)(mx-data->draglastx))/deler) * (fabs(data->dragstartx-mx)*0.002);
} else if (!ui_is_but_float(but) && but->max-but->min > 129) { /* only scale large int buttons */
/* non linear change in mouse input- good for high precicsionm ints need less fine tuning */
data->dragf+= (((float)(mx-data->draglastx))/deler) * (fabs(data->dragstartx-mx)*0.004);
} else {
/*no scaling */
data->dragf+= ((float)(mx-data->draglastx))/deler ;
}
if(data->dragf>1.0) data->dragf= 1.0;
if(data->dragf<0.0) data->dragf= 0.0;
data->draglastx= mx;
tempf= ( but->min + data->dragf*(but->max-but->min));
if(!ui_is_but_float(but)) {
temp= floor(tempf+.5);
if(tempf==but->min || tempf==but->max);
else if(snap) {
if(snap == 2) temp= 100*(temp/100);
else temp= 10*(temp/10);
}
if( temp>=but->min && temp<=but->max) {
lvalue= (int)data->value;
if(temp != lvalue ) {
data->dragchange= 1;
data->value= (double)temp;
changed= 1;
}
}
}
else {
temp= 0;
if(snap) {
if(snap == 2) {
if(tempf==but->min || tempf==but->max);
else if(but->max-but->min < 2.10) tempf= 0.01*floor(100.0*tempf);
else if(but->max-but->min < 21.0) tempf= 0.1*floor(10.0*tempf);
else tempf= floor(tempf);
}
else {
if(tempf==but->min || tempf==but->max);
else if(but->max-but->min < 2.10) tempf= 0.1*floor(10*tempf);
else if(but->max-but->min < 21.0) tempf= floor(tempf);
else tempf= 10.0*floor(tempf/10.0);
}
}
if( tempf>=but->min && tempf<=but->max) {
if(tempf != data->value) {
data->dragchange= 1;
data->value= tempf;
changed= 1;
}
}
}
return changed;
}
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
static int ui_do_but_NUM(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 mx, my, click= 0;
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
int retval= WM_UI_HANDLER_CONTINUE;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(event->val) {
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->shift) {
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(event->type == LEFTMOUSE) {
data->dragstartx= mx;
data->draglastx= mx;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(ELEM(event->type, PADENTER, RETKEY) && event->val)
click= 1;
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == LEFTMOUSE && event->val==0) {
if(data->dragchange)
button_activate_state(C, but, BUTTON_STATE_EXIT);
else
click= 1;
}
else if(event->type == MOUSEMOVE) {
float fac;
int snap;
fac= 1.0f;
if(event->shift) fac /= 10.0f;
if(event->alt) fac /= 20.0f;
Work on gesture, some more cleaning. - Added standard "tweak" gesture operator, which can be set per region, to generate EVT_TWEAK events. You can configure tweaks for any mouse button and have handlers for such events check for modifiers etc. It even stores tweak direction (8 directions). Might be fun to experiment with tweak gestures N, S, etc. :) In general it can be used to replace the current tweak code in 2.48 (std_rmouse_transform). Test added: on screen level it now adds LMB tweaks, if tweak-South it splits the area. Will be removed of course. - Added to Border operator a property to store event used to end border with. - Moved the "AZone" triangle drawing to the right context (area). It was on screen level, not respecting area-redraws. Also cleaned up drawing for it, and moved the "swap buffers indicator" square to look nicer. Those squares are only for test! - event-match function had bad code for checking for event-value. Made a "KM_ANY" define so keymaps can be defined ignoring event values. - Gesture todo: lasso, "real gesture" (like blender now has)
2008-11-24 10:45:36 +00:00
if(event->custom == EVT_DATA_TABLET) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
wmTabletData *wmtab= event->customdata;
/* de-sensitise based on tablet pressure */
if (ELEM(wmtab->Active, DEV_STYLUS, DEV_ERASER))
fac *= wmtab->Pressure;
}
snap= (event->ctrl)? (event->shift)? 2: 1: 0;
if(ui_numedit_but_NUM(but, data, fac, snap, mx))
ui_numedit_apply(C, block, but, data);
}
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
else if(data->state == BUTTON_STATE_TEXT_EDITING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit(C, block, but, data, event);
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
retval= WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
else if(data->state == BUTTON_STATE_TEXT_SELECTING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit_select(C, block, but, data, event);
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
retval= WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(click) {
/* we can click on the side arrows to increment/decrement,
* or click inside to edit the value directly */
float tempf;
int temp;
if(!ui_is_but_float(but)) {
if(mx < (but->x1 + (but->x2 - but->x1)/3 - 3)) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
temp= (int)data->value - 1;
if(temp>=but->min && temp<=but->max)
data->value= (double)temp;
else
data->cancel= 1;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else if(mx > (but->x1 + (2*(but->x2 - but->x1)/3) + 3)) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
temp= (int)data->value + 1;
if(temp>=but->min && temp<=but->max)
data->value= (double)temp;
else
data->cancel= 1;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
}
else {
if(mx < (but->x1 + (but->x2 - but->x1)/3 - 3)) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
tempf= data->value - 0.01*but->a1;
if (tempf < but->min) tempf = but->min;
data->value= tempf;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else if(mx > but->x1 + (2*((but->x2 - but->x1)/3) + 3)) {
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
tempf= data->value + 0.01*but->a1;
if (tempf < but->min) tempf = but->min;
data->value= tempf;
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
}
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_numedit_but_SLI(uiBut *but, uiHandleButtonData *data, int shift, int ctrl, int mx)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
float deler, f, tempf;
int temp, lvalue, changed= 0;
if(but->type==NUMSLI) deler= ((but->x2-but->x1)/2 - 5.0*but->aspect);
else if(but->type==HSVSLI) deler= ((but->x2-but->x1)/2 - 5.0*but->aspect);
else deler= (but->x2-but->x1- 5.0*but->aspect);
f= (float)(mx-data->dragstartx)/deler + data->dragfstart;
if(shift)
f= (f-data->dragfstart)/10.0 + data->dragfstart;
CLAMP(f, 0.0, 1.0);
tempf= but->min+f*(but->max-but->min);
temp= floor(tempf+.5);
if(ctrl) {
if(tempf==but->min || tempf==but->max);
else if(ui_is_but_float(but)) {
if(shift) {
if(tempf==but->min || tempf==but->max);
else if(but->max-but->min < 2.10) tempf= 0.01*floor(100.0*tempf);
else if(but->max-but->min < 21.0) tempf= 0.1*floor(10.0*tempf);
else tempf= floor(tempf);
}
else {
if(but->max-but->min < 2.10) tempf= 0.1*floor(10*tempf);
else if(but->max-but->min < 21.0) tempf= floor(tempf);
else tempf= 10.0*floor(tempf/10.0);
}
}
else {
temp= 10*(temp/10);
tempf= temp;
}
}
if(!ui_is_but_float(but)) {
lvalue= floor(data->value+0.5);
if(temp != lvalue) {
data->value= temp;
data->dragchange= 1;
changed= 1;
}
}
else {
if(tempf != data->value) {
data->value= tempf;
data->dragchange= 1;
changed= 1;
}
}
return changed;
}
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
static int ui_do_but_SLI(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 mx, my, click= 0;
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
int retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
/* start either dragging as slider, or editing as text */
if(mx>= -6+(but->x1+but->x2)/2) {
if(event->type == LEFTMOUSE) {
data->dragstartx= mx;
data->draglastx= mx;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
}
else
click= 1;
}
else
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == LEFTMOUSE && event->val==0) {
if(data->dragchange)
button_activate_state(C, but, BUTTON_STATE_EXIT);
else
click= 1;
}
else if(event->type == MOUSEMOVE) {
if(ui_numedit_but_SLI(but, data, event->shift, event->ctrl, mx))
ui_numedit_apply(C, block, but, data);
}
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
else if(data->state == BUTTON_STATE_TEXT_EDITING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit(C, block, but, data, event);
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
retval= WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
else if(data->state == BUTTON_STATE_TEXT_SELECTING) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_do_but_textedit_select(C, block, but, data, event);
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
retval= WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(click) {
float f, h;
float tempf;
int temp;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
tempf= data->value;
temp= (int)data->value;
h= but->y2-but->y1;
if(but->type==SLI) f= (float)(mx-but->x1)/(but->x2-but->x1-h);
else f= (float)(mx- (but->x1+but->x2)/2)/((but->x2-but->x1)/2 - h);
f= but->min+f*(but->max-but->min);
if(!ui_is_but_float(but)) {
if(f<temp) temp--;
else temp++;
if(temp>=but->min && temp<=but->max)
data->value= temp;
else
data->cancel= 1;
}
else {
if(f<tempf) tempf-=.01;
else tempf+=.01;
if(tempf>=but->min && tempf<=but->max)
data->value= tempf;
else
data->cancel= 1;
}
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_do_but_BLOCK(bContext *C, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
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
button_activate_state(C, but, BUTTON_STATE_MENU_OPEN);
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_numedit_but_NORMAL(uiBut *but, uiHandleButtonData *data, int mx, int my)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
float dx, dy, rad, radsq, mrad, *fp;
int mdx, mdy, changed= 1;
/* button is presumed square */
/* if mouse moves outside of sphere, it does negative normal */
fp= data->origvec;
rad= (but->x2 - but->x1);
radsq= rad*rad;
if(fp[2]>0.0f) {
mdx= (rad*fp[0]);
mdy= (rad*fp[1]);
}
else if(fp[2]> -1.0f) {
mrad= rad/sqrt(fp[0]*fp[0] + fp[1]*fp[1]);
mdx= 2.0f*mrad*fp[0] - (rad*fp[0]);
mdy= 2.0f*mrad*fp[1] - (rad*fp[1]);
}
else mdx= mdy= 0;
dx= (float)(mx+mdx-data->dragstartx);
dy= (float)(my+mdy-data->dragstarty);
fp= data->vec;
mrad= dx*dx+dy*dy;
if(mrad < radsq) { /* inner circle */
fp[0]= dx;
fp[1]= dy;
fp[2]= sqrt( radsq-dx*dx-dy*dy );
}
else { /* outer circle */
mrad= rad/sqrt(mrad); // veclen
dx*= (2.0f*mrad - 1.0f);
dy*= (2.0f*mrad - 1.0f);
mrad= dx*dx+dy*dy;
if(mrad < radsq) {
fp[0]= dx;
fp[1]= dy;
fp[2]= -sqrt( radsq-dx*dx-dy*dy );
}
}
Normalize(fp);
data->draglastx= mx;
data->draglasty= my;
return changed;
}
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
static int ui_do_but_NORMAL(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 mx, my;
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(event->type==LEFTMOUSE && event->val) {
data->dragstartx= mx;
data->dragstarty= my;
data->draglastx= mx;
data->draglasty= my;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
/* also do drag the first time */
if(ui_numedit_but_NORMAL(but, data, mx, my))
ui_numedit_apply(C, block, but, data);
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == MOUSEMOVE) {
if(mx!=data->draglastx || my!=data->draglasty) {
if(ui_numedit_but_NORMAL(but, data, mx, my))
ui_numedit_apply(C, block, but, data);
}
}
else if(event->type==LEFTMOUSE && event->val==0)
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_numedit_but_HSVCUBE(uiBut *but, uiHandleButtonData *data, int mx, int my)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
float x, y;
int changed= 1;
/* relative position within box */
x= ((float)mx-but->x1)/(but->x2-but->x1);
y= ((float)my-but->y1)/(but->y2-but->y1);
CLAMP(x, 0.0, 1.0);
CLAMP(y, 0.0, 1.0);
if(but->a1==0) {
but->hsv[0]= x;
but->hsv[2]= y;
}
else if(but->a1==1) {
but->hsv[0]= x;
but->hsv[1]= y;
}
else if(but->a1==2) {
but->hsv[2]= x;
but->hsv[1]= y;
}
else
but->hsv[0]= x;
ui_set_but_hsv(but); // converts to rgb
// update button values and strings
ui_update_block_buts_hsv(but->block, but->hsv);
data->draglastx= mx;
data->draglasty= my;
return changed;
}
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
static int ui_do_but_HSVCUBE(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 mx, my;
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(event->type==LEFTMOUSE && event->val) {
data->dragstartx= mx;
data->dragstarty= my;
data->draglastx= mx;
data->draglasty= my;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
/* also do drag the first time */
if(ui_numedit_but_HSVCUBE(but, data, mx, my))
ui_numedit_apply(C, block, but, data);
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == MOUSEMOVE) {
if(mx!=data->draglastx || my!=data->draglasty) {
if(ui_numedit_but_HSVCUBE(but, data, mx, my))
ui_numedit_apply(C, block, but, data);
}
}
else if(event->type==LEFTMOUSE && event->val==0)
button_activate_state(C, but, BUTTON_STATE_EXIT);
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
static int verg_colorband(const void *a1, const void *a2)
{
const CBData *x1=a1, *x2=a2;
if( x1->pos > x2->pos ) return 1;
else if( x1->pos < x2->pos) return -1;
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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
static void ui_colorband_update(ColorBand *coba)
{
int a;
if(coba->tot<2) return;
for(a=0; a<coba->tot; a++) coba->data[a].cur= a;
qsort(coba->data, coba->tot, sizeof(CBData), verg_colorband);
for(a=0; a<coba->tot; a++) {
if(coba->data[a].cur==coba->cur) {
coba->cur= a;
break;
}
}
}
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
static int ui_numedit_but_COLORBAND(uiBut *but, uiHandleButtonData *data, int mx)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
float dx;
int changed= 0;
if(data->draglastx == mx)
return changed;
dx= ((float)(mx - data->draglastx))/(but->x2-but->x1);
data->dragcbd->pos += dx;
CLAMP(data->dragcbd->pos, 0.0, 1.0);
ui_colorband_update(data->coba);
data->dragcbd= data->coba->data + data->coba->cur; /* because qsort */
data->draglastx= mx;
changed= 1;
return changed;
}
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
static int ui_do_but_COLORBAND(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
ColorBand *coba;
CBData *cbd;
int mx, my, a, xco, mindist= 12;
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(event->type==LEFTMOUSE && event->val) {
coba= (ColorBand*)but->poin;
if(event->ctrl) {
/* insert new key on mouse location */
if(coba->tot < MAXCOLORBAND-1) {
float pos= ((float)(mx - but->x1))/(but->x2-but->x1);
float col[4];
do_colorband(coba, pos, col); /* executes it */
coba->tot++;
coba->cur= coba->tot-1;
coba->data[coba->cur].r= col[0];
coba->data[coba->cur].g= col[1];
coba->data[coba->cur].b= col[2];
coba->data[coba->cur].a= col[3];
coba->data[coba->cur].pos= pos;
ui_colorband_update(coba);
}
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
else {
data->dragstartx= mx;
data->dragstarty= my;
data->draglastx= mx;
data->draglasty= my;
/* activate new key when mouse is close */
for(a=0, cbd= coba->data; a<coba->tot; a++, cbd++) {
xco= but->x1 + (cbd->pos*(but->x2-but->x1));
xco= ABS(xco-mx);
if(a==coba->cur) xco+= 5; // selected one disadvantage
if(xco<mindist) {
coba->cur= a;
mindist= xco;
}
}
data->dragcbd= coba->data + coba->cur;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
}
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == MOUSEMOVE) {
if(mx!=data->draglastx || my!=data->draglasty) {
if(ui_numedit_but_COLORBAND(but, data, mx))
ui_numedit_apply(C, block, but, data);
}
}
else if(event->type==LEFTMOUSE && event->val==0)
button_activate_state(C, but, BUTTON_STATE_EXIT);
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_numedit_but_CURVE(uiBut *but, uiHandleButtonData *data, int snap, int mx, int my)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
CurveMapping *cumap= data->cumap;
CurveMap *cuma= cumap->cm+cumap->cur;
CurveMapPoint *cmp= cuma->curve;
float fx, fy, zoomx, zoomy, offsx, offsy;
int a, changed= 0;
zoomx= (but->x2-but->x1)/(cumap->curr.xmax-cumap->curr.xmin);
zoomy= (but->y2-but->y1)/(cumap->curr.ymax-cumap->curr.ymin);
offsx= cumap->curr.xmin;
offsy= cumap->curr.ymin;
if(data->dragsel != -1) {
int moved_point= 0; /* for ctrl grid, can't use orig coords because of sorting */
fx= (mx-data->draglastx)/zoomx;
fy= (my-data->draglasty)/zoomy;
for(a=0; a<cuma->totpoint; a++) {
if(cmp[a].flag & SELECT) {
float origx= cmp[a].x, origy= cmp[a].y;
cmp[a].x+= fx;
cmp[a].y+= fy;
if(snap) {
cmp[a].x= 0.125f*floor(0.5f + 8.0f*cmp[a].x);
cmp[a].y= 0.125f*floor(0.5f + 8.0f*cmp[a].y);
}
if(cmp[a].x!=origx || cmp[a].y!=origy)
moved_point= 1;
}
}
curvemapping_changed(cumap, 0); /* no remove doubles */
if(moved_point) {
data->draglastx= mx;
data->draglasty= my;
changed= 1;
}
data->dragchange= 1; /* mark for selection */
}
else {
fx= (mx-data->draglastx)/zoomx;
fy= (my-data->draglasty)/zoomy;
/* clamp for clip */
if(cumap->flag & CUMA_DO_CLIP) {
if(cumap->curr.xmin-fx < cumap->clipr.xmin)
fx= cumap->curr.xmin - cumap->clipr.xmin;
else if(cumap->curr.xmax-fx > cumap->clipr.xmax)
fx= cumap->curr.xmax - cumap->clipr.xmax;
if(cumap->curr.ymin-fy < cumap->clipr.ymin)
fy= cumap->curr.ymin - cumap->clipr.ymin;
else if(cumap->curr.ymax-fy > cumap->clipr.ymax)
fy= cumap->curr.ymax - cumap->clipr.ymax;
}
cumap->curr.xmin-=fx;
cumap->curr.ymin-=fy;
cumap->curr.xmax-=fx;
cumap->curr.ymax-=fy;
data->draglastx= mx;
data->draglasty= my;
changed= 1;
}
return changed;
}
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
static int ui_do_but_CURVE(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 mx, my, a, changed= 0;
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(event->type==LEFTMOUSE && event->val) {
CurveMapping *cumap= (CurveMapping*)but->poin;
CurveMap *cuma= cumap->cm+cumap->cur;
CurveMapPoint *cmp= cuma->curve;
float fx, fy, zoomx, zoomy, offsx, offsy;
float dist, mindist= 200.0f; // 14 pixels radius
int sel= -1;
zoomx= (but->x2-but->x1)/(cumap->curr.xmax-cumap->curr.xmin);
zoomy= (but->y2-but->y1)/(cumap->curr.ymax-cumap->curr.ymin);
offsx= cumap->curr.xmin;
offsy= cumap->curr.ymin;
if(event->ctrl) {
fx= ((float)my - but->x1)/zoomx + offsx;
fy= ((float)my - but->y1)/zoomy + offsy;
curvemap_insert(cuma, fx, fy);
curvemapping_changed(cumap, 0);
changed= 1;
}
/* check for selecting of a point */
cmp= cuma->curve; /* ctrl adds point, new malloc */
for(a=0; a<cuma->totpoint; a++) {
fx= but->x1 + zoomx*(cmp[a].x-offsx);
fy= but->y1 + zoomy*(cmp[a].y-offsy);
dist= (fx-mx)*(fx-mx) + (fy-my)*(fy-my);
if(dist < mindist) {
sel= a;
mindist= dist;
}
}
if (sel == -1) {
/* if the click didn't select anything, check if it's clicked on the
* curve itself, and if so, add a point */
fx= ((float)mx - but->x1)/zoomx + offsx;
fy= ((float)my - but->y1)/zoomy + offsy;
cmp= cuma->table;
/* loop through the curve segment table and find what's near the mouse.
* 0.05 is kinda arbitrary, but seems to be what works nicely. */
for(a=0; a<=CM_TABLE; a++) {
if ( ( fabs(fx - cmp[a].x) < (0.05) ) && ( fabs(fy - cmp[a].y) < (0.05) ) ) {
curvemap_insert(cuma, fx, fy);
curvemapping_changed(cumap, 0);
changed= 1;
/* reset cmp back to the curve points again, rather than drawing segments */
cmp= cuma->curve;
/* find newly added point and make it 'sel' */
for(a=0; a<cuma->totpoint; a++)
if(cmp[a].x == fx)
sel = a;
break;
}
}
}
if(sel!= -1) {
/* ok, we move a point */
/* deselect all if this one is deselect. except if we hold shift */
if(event->shift==0 && (cmp[sel].flag & SELECT)==0)
for(a=0; a<cuma->totpoint; a++)
cmp[a].flag &= ~SELECT;
cmp[sel].flag |= SELECT;
}
else {
/* move the view */
data->cancel= 1;
}
data->dragsel= sel;
data->dragstartx= mx;
data->dragstarty= my;
data->draglastx= mx;
data->draglasty= my;
button_activate_state(C, but, BUTTON_STATE_NUM_EDITING);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
else if(data->state == BUTTON_STATE_NUM_EDITING) {
if(event->type == MOUSEMOVE) {
if(mx!=data->draglastx || my!=data->draglasty) {
if(ui_numedit_but_CURVE(but, data, event->shift, mx, my))
ui_numedit_apply(C, block, but, data);
}
}
else if(event->type==LEFTMOUSE && event->val==0) {
if(data->dragsel != -1) {
CurveMapping *cumap= data->cumap;
CurveMap *cuma= cumap->cm+cumap->cur;
CurveMapPoint *cmp= cuma->curve;
if(!data->dragchange) {
/* deselect all, select one */
if(event->shift==0) {
for(a=0; a<cuma->totpoint; a++)
cmp[a].flag &= ~SELECT;
cmp[data->dragsel].flag |= SELECT;
}
}
else
curvemapping_changed(cumap, 1); /* remove doubles */
}
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
#ifdef INTERNATIONAL
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
static int ui_do_but_CHARTAB(bContext *C, uiBlock *block, uiBut *but, uiHandleButtonData *data, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 bad global and state access */
#if 0
float sx, sy, ex, ey;
float width, height;
float butw, buth;
int mx, my, x, y, cs, che;
mx= event->x;
my= event->y;
ui_window_to_block(data->region, block, &mx, &my);
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(ELEM3(event->type, LEFTMOUSE, PADENTER, RETKEY) && event->val) {
/* Calculate the size of the button */
width = abs(but->x2 - but->x1);
height = abs(but->y2 - but->y1);
butw = floor(width / 12);
buth = floor(height / 6);
/* Initialize variables */
sx = but->x1;
ex = but->x1 + butw;
sy = but->y1 + height - buth;
ey = but->y1 + height;
cs = G.charstart;
/* And the character is */
x = (int) ((mx / butw) - 0.5);
y = (int) (6 - ((my / buth) - 0.5));
che = cs + (y*12) + x;
if(che > G.charmax)
che = 0;
if(G.obedit)
{
do_textedit(0,0,che);
}
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(ELEM(event->type, WHEELUPMOUSE, PAGEUPKEY)) {
for(but= block->buttons.first; but; but= but->next) {
if(but->type == CHARTAB) {
G.charstart = G.charstart - (12*6);
if(G.charstart < 0)
G.charstart = 0;
if(G.charstart < G.charmin)
G.charstart = G.charmin;
ui_draw_but(but);
//Really nasty... to update the num button from the same butblock
for(bt= block->buttons.first; bt; bt= bt->next)
{
if(ELEM(bt->type, NUM, NUMABS)) {
ui_check_but(bt);
ui_draw_but(bt);
}
}
retval=UI_CONT;
break;
}
}
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(ELEM(event->type, WHEELDOWNMOUSE, PAGEDOWNKEY)) {
for(but= block->buttons.first; but; but= but->next)
{
if(but->type == CHARTAB)
{
G.charstart = G.charstart + (12*6);
if(G.charstart > (0xffff - 12*6))
G.charstart = 0xffff - (12*6);
if(G.charstart > G.charmax - 12*6)
G.charstart = G.charmax - 12*6;
ui_draw_but(but);
for(bt= block->buttons.first; bt; bt= bt->next)
{
if(ELEM(bt->type, NUM, NUMABS)) {
ui_check_but(bt);
ui_draw_but(bt);
}
}
but->flag |= UI_ACTIVE;
retval=UI_RETURN_OK;
break;
}
}
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
#endif
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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
#endif
static int ui_do_button(bContext *C, uiBlock *block, uiBut *but, wmEvent *event)
{
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
uiHandleButtonData *data;
int retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
data= but->active;
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* handle copy-paste */
if(data->state == BUTTON_STATE_HIGHLIGHT) {
if(ELEM(event->type, CKEY, VKEY) && event->val && (event->ctrl || event->oskey)) {
ui_but_copy_paste(C, but, data, (event->type == CKEY)? 'c': 'v');
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
/* verify if we can edit this button */
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
if(ELEM(event->type, LEFTMOUSE, RETKEY)) {
if(but->lock) {
if(but->lockstr) {
WM_report(C, WM_LOG_WARNING, but->lockstr);
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
2.5 Fix: the main button handler was swallowing all events. Now every button type returns 'handled' only if it did something, so other events get nicely processed. This will enable MMB pan in dataviewer.
2008-12-03 14:22:42 +00:00
}
}
else if(but->pointype && but->poin==0) {
/* there's a pointer needed */
WM_reportf(C, WM_LOG_WARNING, "DoButton pointer error: %s", 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
button_activate_state(C, but, BUTTON_STATE_EXIT);
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
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
switch(but->type) {
case BUT:
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
retval= ui_do_but_BUT(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case KEYEVT:
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
retval= ui_do_but_KEYEVT(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case TOG:
case TOGR:
case ICONTOG:
case ICONTOGN:
case TOGN:
case BUT_TOGDUAL:
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
retval= ui_do_but_TOG(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
#if 0
case SCROLL:
/* DrawBut(b, 1); */
/* do_scrollbut(b); */
/* DrawBut(b,0); */
break;
#endif
case NUM:
case NUMABS:
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
retval= ui_do_but_NUM(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case SLI:
case NUMSLI:
case HSVSLI:
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
retval= ui_do_but_SLI(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case ROUNDBOX:
case LABEL:
case TOG3:
case ROW:
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
retval= ui_do_but_EXIT(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case TEX:
case IDPOIN:
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
retval= ui_do_but_TEX(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case MENU:
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
retval= ui_do_but_BLOCK(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case ICONROW:
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
retval= ui_do_but_BLOCK(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case ICONTEXTROW:
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
retval= ui_do_but_BLOCK(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BLOCK:
case PULLDOWN:
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
retval= ui_do_but_BLOCK(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BUTM:
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
retval= ui_do_but_BUT(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case COL:
if(but->a1 == -1) // signal to prevent calling up color picker
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
retval= ui_do_but_EXIT(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
else
UI: 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
retval= ui_do_but_BLOCK(C, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BUT_NORMAL:
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
retval= ui_do_but_NORMAL(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BUT_COLORBAND:
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
retval= ui_do_but_COLORBAND(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case BUT_CURVE:
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
retval= ui_do_but_CURVE(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
case HSVCUBE:
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
retval= ui_do_but_HSVCUBE(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
#ifdef INTERNATIONAL
case CHARTAB:
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
retval= ui_do_but_CHARTAB(C, block, but, data, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
#endif
/* XXX 2.50 links not implemented yet */
#if 0
case LINK:
case INLINK:
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
retval= retval= ui_do_but_LINK(block, but);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
break;
#endif
}
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
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
/* ************************ button utilities *********************** */
static int ui_but_contains_pt(uiBut *but, int mx, int my)
{
return ((but->x1<mx && but->x2>=mx) && (but->y1<my && but->y2>=my));
}
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
static uiBut *ui_but_find_activated(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
{
uiBlock *block;
uiBut *but;
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
for(block=ar->uiblocks.first; block; block=block->next)
for(but=block->buttons.first; but; but= but->next)
if(but->active)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
return but;
return NULL;
}
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
static void ui_blocks_set_tooltips(ARegion *ar, int enable)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
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
/* we disabled buttons when when they were already shown, and
* re-enable them on mouse move */
for(block=ar->uiblocks.first; block; block=block->next)
block->tooltipdisabled= !enable;
2.5 Another view2d fix: buttons now get clipped for region and mask, so sliders will work fine, but also buttons overlapping region edges.
2008-12-03 18:14:52 +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
static uiBut *ui_but_find_mouse_over(ARegion *ar, 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
{
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
uiBlock *block;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
uiBut *but, *butover= NULL;
int mx, my;
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
/* check if the mouse is in the region, and in case of a view2d also check
* if it is inside the view2d itself, not over scrollbars for example */
if(!BLI_in_rcti(&ar->winrct, x, y))
return NULL;
2.5 Another view2d fix: buttons now get clipped for region and mask, so sliders will work fine, but also buttons overlapping region edges.
2008-12-03 18:14:52 +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
if(ar->v2d.mask.xmin!=ar->v2d.mask.xmax) {
mx= x;
my= y;
ui_window_to_region(ar, &mx, &my);
if(!BLI_in_rcti(&ar->v2d.mask, mx, my))
return NULL;
}
for(block=ar->uiblocks.first; block; block=block->next) {
mx= x;
my= y;
ui_window_to_block(ar, block, &mx, &my);
for(but=block->buttons.first; but; but= but->next) {
/* give precedence to already activated buttons */
if(ui_but_contains_pt(but, mx, my))
if(!butover || (!butover->active && but->active))
butover= but;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
return butover;
}
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
/* ****************** button state handling **************************/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int button_modal_state(uiHandleButtonState state)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
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
return ELEM6(state, BUTTON_STATE_WAIT_RELEASE, BUTTON_STATE_WAIT_KEY_EVENT,
BUTTON_STATE_NUM_EDITING, BUTTON_STATE_TEXT_EDITING,
BUTTON_STATE_TEXT_SELECTING, BUTTON_STATE_MENU_OPEN);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static void button_tooltip_timer_start(uiBut *but)
{
uiHandleButtonData *data;
data= but->active;
/* XXX 2.50 U missing from context */
if(U.flag & USER_TOOLTIPS)
if(!data->tooltiptimer && !but->block->tooltipdisabled)
data->tooltiptimer= WM_event_add_window_timer(data->window, BUTTON_TOOLTIP_DELAY, ~0);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
static void button_activate_state(bContext *C, uiBut *but, uiHandleButtonState state)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
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
uiHandleButtonData *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
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
data= but->active;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(data->state == state)
return;
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
/* highlight has timers for tooltips and auto open */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(state == BUTTON_STATE_HIGHLIGHT) {
but->flag &= ~UI_SELECT;
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
button_tooltip_timer_start(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
/* automatic open pulldown block timer */
if(but->type==BLOCK || but->type==MENU || but->type==PULLDOWN || but->type==ICONTEXTROW) {
if(!data->autoopentimer) {
int time;
if(but->block->auto_open==2) time= 1; // test for toolbox
else if(but->block->flag & UI_BLOCK_LOOP || but->block->auto_open) time= 5*U.menuthreshold2;
else if(U.uiflag & USER_MENUOPENAUTO) time= 5*U.menuthreshold1;
else time= -1;
if(time >= 0)
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
data->autoopentimer= WM_event_add_window_timer(data->window, time*20, ~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 {
but->flag |= UI_SELECT;
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
if(data->tooltiptimer) {
WM_event_remove_window_timer(data->window, data->tooltiptimer);
data->tooltiptimer= NULL;
}
if(data->tooltip) {
ui_tooltip_free(C, data->tooltip);
data->tooltip= NULL;
}
if(data->autoopentimer) {
WM_event_remove_window_timer(data->window, data->autoopentimer);
data->autoopentimer= 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
}
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
/* text editing */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(state == BUTTON_STATE_TEXT_EDITING && data->state != BUTTON_STATE_TEXT_SELECTING)
ui_textedit_begin(but, data);
else if(data->state == BUTTON_STATE_TEXT_EDITING && state != BUTTON_STATE_TEXT_SELECTING)
ui_textedit_end(but, data);
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
/* number editing */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(state == BUTTON_STATE_NUM_EDITING)
ui_numedit_begin(but, data);
else if(data->state == BUTTON_STATE_NUM_EDITING)
ui_numedit_end(but, data);
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
/* menu open */
if(state == BUTTON_STATE_MENU_OPEN)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_blockopen_begin(C, but, data);
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
else if(data->state == BUTTON_STATE_MENU_OPEN)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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_blockopen_end(C, but, data);
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
/* add a short delay before exiting, to ensure there is some feedback */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(state == BUTTON_STATE_WAIT_FLASH) {
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
data->flashtimer= WM_event_add_window_timer(data->window, BUTTON_FLASH_DELAY, ~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 if(data->flashtimer) {
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
WM_event_remove_window_timer(data->window, data->flashtimer);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->flashtimer= NULL;
}
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
/* add a blocking ui handler at the window handler for blocking, modal states */
if(button_modal_state(state)) {
if(!button_modal_state(data->state))
WM_event_add_ui_handler(C, &data->window->handlers, ui_handler_window, NULL);
}
else {
if(button_modal_state(data->state))
WM_event_remove_ui_handler(&data->window->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
data->state= state;
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
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
static void button_activate_init(bContext *C, ARegion *ar, uiBut *but, uiButtonActivateType 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
uiHandleButtonData *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
/* setup struct */
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
data= MEM_callocN(sizeof(uiHandleButtonData), "uiHandleButtonData");
data->window= C->window;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->region= ar;
data->interactive= 0;
data->state = BUTTON_STATE_INIT;
/* activate button */
but->flag |= UI_ACTIVE;
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
but->active= 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
/* we disable auto_open in the block after a threshold, because we still
* want to allow auto opening adjacent menus even if no button is activated
* inbetween going over to the other button, but only for a short while */
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
if(type == BUTTON_ACTIVATE_OVER && but->block->auto_open)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(but->block->auto_open_last+BUTTON_AUTO_OPEN_THRESH < PIL_check_seconds_timer())
but->block->auto_open= 0;
Lots of stuff; couldn't commit in parts because of refactor work. * Changes in interface/ module This commit brings back the way how buttons/menus work under control of WM event system. The previous implementation extended usage of handlers and operators in an interesting but confusing way. Better to try it first according the design specs. :) Most obviously: - modal-handler operators are not stored anymore in regions/areas/windows. such modal handlers own their operator, and should remove it themselves. - removed code to move handlers from one queue to another. (needs review with brecht!) - WM fix: the API call to remove a modal handler got removed. This was a dangerous thing anyway, and you should leave that to the event system. Now, if a handler modal() call gets a cancel/finish return, it frees itself in event system. WM_event_remove_modal_handler was a confusing call anyway! Todo: - allow button-activate to refresh after using button - re-enable arrow keys for menus (do both after commit) - review return values of operator callbacks in interface_ops.c * Fixes in WM system - Freeing areas/regions/windows, also on quit, now correctly closes running modal handlers - On starting a modal handler, the handler now stores previous area and region context, so they send proper notifiers etc. * Other fixes - Area-split operator had bug, wrong minimal size checking. This solves error when trying to split a very narrow area. - removed DNA_USHORT_FIX from screen_types.h, gave warning - operators didn't get ID name copied when activated, needed for later re-use or saving.
2008-12-02 14:22:52 +00:00
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_HIGHLIGHT);
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
if(type == BUTTON_ACTIVATE_OPEN)
button_activate_state(C, but, BUTTON_STATE_MENU_OPEN);
else if(type == BUTTON_ACTIVATE_TEXT_EDITING)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_TEXT_EDITING);
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
else if(type == BUTTON_ACTIVATE_APPLY)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
button_activate_state(C, but, BUTTON_STATE_WAIT_FLASH);
}
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
static void button_activate_exit(bContext *C, uiHandleButtonData *data, uiBut *but, int mousemove)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
uiBlock *block= 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
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
/* ensure we are in the exit state */
if(data->state != BUTTON_STATE_EXIT)
button_activate_state(C, but, BUTTON_STATE_EXIT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
/* if this button is in a menu, this will set the button return
* value to the button value and the menu return value to ok, the
* menu return value will be picked up and the menu will close */
if(block->handle && !(block->flag & UI_BLOCK_KEEP_OPEN) && !data->cancel) {
uiMenuBlockHandle *handle;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
handle= block->handle;
handle->butretval= data->retval;
handle->menuretval= UI_RETURN_OK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* apply the button action or value */
UI: * Added context pointer to function callbacks for buttons and blocks. * Added a uiBlockSetHandleFunc, which will be called with the button return value. This seems kind of redundant with uiBlockSetButmFunc, but the latter uses a2 to pass the value.
2008-12-10 19:22:10 +00:00
ui_apply_button(C, block, but, data, 0);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
/* disable tooltips until mousemove */
ui_blocks_set_tooltips(data->region, 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
/* clean up */
if(data->str)
MEM_freeN(data->str);
if(data->origstr)
MEM_freeN(data->origstr);
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
/* clean up button */
MEM_freeN(but->active);
but->active= NULL;
but->flag &= ~(UI_ACTIVE|UI_SELECT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
/* redraw */
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
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
/* adds empty mousemove in queue for re-init handler, in case mouse is
* still over a button. we cannot just check for this ourselfs because
* at this point the mouse may be over a button in another region */
if(mousemove)
WM_event_add_mousemove(C);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
void ui_button_active_cancel(const bContext *C, uiBut *but)
{
uiHandleButtonData *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
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
/* this gets called when the button somehow disappears while it is still
* active, this is bad for user interaction, but we need to handle this
* case cleanly anyway in case it happens */
if(but->active) {
data= but->active;
data->cancel= 1;
button_activate_exit((bContext*)C, data, but, 0);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
UI: 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
/************** handle activating a button *************/
static int ui_handle_button_over(bContext *C, wmEvent *event, ARegion *ar)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
uiBut *but;
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
if(event->type == MOUSEMOVE) {
but= ui_but_find_mouse_over(ar, event->x, event->y);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
if(but)
button_activate_init(C, ar, but, BUTTON_ACTIVATE_OVER);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
return WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static void ui_handle_button_activate(bContext *C, ARegion *ar, uiBut *but, uiButtonActivateType 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
uiBut *oldbut;
uiHandleButtonData *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
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
oldbut= ui_but_find_activated(ar);
if(oldbut) {
data= oldbut->active;
data->cancel= 1;
button_activate_exit(C, data, oldbut, 0);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
button_activate_init(C, ar, but, 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
/************ handle events for an activated button ***********/
static int ui_handle_button_event(bContext *C, wmEvent *event, uiBut *but)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: 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
uiHandleButtonData *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
uiBlock *block;
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
ARegion *ar;
uiBut *postbut;
uiButtonActivateType posttype;
int retval, mx, my;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
data= but->active;
block= but->block;
ar= data->region;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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(data->state == BUTTON_STATE_HIGHLIGHT) {
switch(event->type) {
case MOUSEMOVE:
/* verify if we are still over the button, if not exit */
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
mx= event->x;
my= event->y;
ui_window_to_block(ar, block, &mx, &my);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
if(!ui_but_contains_pt(but, mx, my)) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->cancel= 1;
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
button_activate_state(C, but, BUTTON_STATE_EXIT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
else if(event->x!=event->prevx || event->y!=event->prevy) {
/* re-enable tooltip on mouse move */
ui_blocks_set_tooltips(ar, 1);
button_tooltip_timer_start(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
break;
case TIMER: {
/* handle tooltip timer */
if(event->customdata == data->tooltiptimer) {
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
WM_event_remove_window_timer(data->window, data->tooltiptimer);
data->tooltiptimer= 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
if(!data->tooltip) {
data->tooltip= ui_tooltip_create(C, data->region, but);
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
}
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
/* handle menu auto open timer */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 if(event->customdata == data->autoopentimer) {
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
WM_event_remove_window_timer(data->window, data->autoopentimer);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
data->autoopentimer= NULL;
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
mx= event->x;
my= event->y;
ui_window_to_block(ar, block, &mx, &my);
if(ui_but_contains_pt(but, mx, my))
button_activate_state(C, but, BUTTON_STATE_MENU_OPEN);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
2.5 Fix crashing in pop-up menus when click. There's something wrong still in handling menu itself, need Brecht too look at that... probably a wrong return value somewhere.
2008-12-03 15:49:41 +00:00
default:
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
/* handle button type specific events */
retval= ui_do_button(C, block, but, event);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 if(data->state == BUTTON_STATE_WAIT_RELEASE) {
switch(event->type) {
case MOUSEMOVE:
/* deselect the button when moving the mouse away */
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
mx= event->x;
my= event->y;
ui_window_to_block(ar, block, &mx, &my);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
if(ui_but_contains_pt(but, mx, my)) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
if(!(but->flag & UI_SELECT)) {
but->flag |= UI_SELECT;
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
data->cancel= 0;
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
}
else {
if(but->flag & UI_SELECT) {
but->flag &= ~UI_SELECT;
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
data->cancel= 1;
2.5 - Made view2d manipulations redraw on area level - simplified call to send Notifiers: WM_event_add_notifier(bContext *C, int type, int value, void *data) This brings back more control to WM, no context messing within operators. :) Handlers that execute operators will be responsible for delivering correct contextes. In general: should lead to making context not exposed, but only readable via some callbacks.
2008-12-03 13:44:16 +00:00
WM_event_add_notifier(C, WM_NOTE_WINDOW_REDRAW, 0, 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
}
}
break;
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
default:
/* otherwise catch mouse release event */
ui_do_button(C, block, but, event);
break;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else if(data->state == BUTTON_STATE_WAIT_FLASH) {
switch(event->type) {
case TIMER: {
if(event->customdata == data->flashtimer)
button_activate_state(C, but, BUTTON_STATE_EXIT);
}
}
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
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
else if(data->state == BUTTON_STATE_MENU_OPEN) {
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
switch(event->type) {
case MOUSEMOVE: {
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
uiBut *bt= ui_but_find_mouse_over(ar, event->x, event->y);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
if(bt && bt->active != 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
data->cancel= 1;
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
button_activate_state(C, but, BUTTON_STATE_EXIT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
break;
}
}
ui_do_button(C, block, but, event);
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
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
else {
ui_do_button(C, block, but, event);
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
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
if(data->state == BUTTON_STATE_EXIT) {
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
postbut= data->postbut;
posttype= data->posttype;
button_activate_exit(C, data, but, (postbut == NULL));
/* for jumping to the next button with tab while text editing */
if(postbut)
button_activate_init(C, ar, postbut, posttype);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static void ui_handle_button_closed_submenu(bContext *C, uiBut *but)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
UI: 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
uiHandleButtonData *data;
uiMenuBlockHandle *handle;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
data= but->active;
handle= data->menu->handle;
/* copy over return values from the closing menu */
if(handle->menuretval == UI_RETURN_OK) {
if(but->type == COL)
VECCOPY(data->vec, handle->retvec)
else if(ELEM3(but->type, MENU, ICONROW, ICONTEXTROW))
data->value= handle->retvalue;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* now change button state or exit, which will close the submenu */
if(ELEM(handle->menuretval, UI_RETURN_OK, UI_RETURN_CANCEL)) {
if(handle->menuretval != UI_RETURN_OK)
data->cancel= 1;
button_activate_exit(C, data, but, 1);
}
else if(handle->menuretval == UI_RETURN_OUT)
button_activate_state(C, but, BUTTON_STATE_HIGHLIGHT);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 navigation helpers ************** */
static uiBut *ui_but_prev(uiBut *but)
{
while(but->prev) {
but= but->prev;
if(but->type!=LABEL && but->type!=SEPR && but->type!=ROUNDBOX) return but;
}
return NULL;
}
static uiBut *ui_but_next(uiBut *but)
{
while(but->next) {
but= but->next;
if(but->type!=LABEL && but->type!=SEPR && but->type!=ROUNDBOX) return but;
}
return NULL;
}
static uiBut *ui_but_first(uiBlock *block)
{
uiBut *but;
but= block->buttons.first;
while(but) {
if(but->type!=LABEL && but->type!=SEPR && but->type!=ROUNDBOX) return but;
but= but->next;
}
return NULL;
}
static uiBut *ui_but_last(uiBlock *block)
{
uiBut *but;
but= block->buttons.last;
while(but) {
if(but->type!=LABEL && but->type!=SEPR && but->type!=ROUNDBOX) return but;
but= but->prev;
}
return NULL;
}
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
/* ************************* menu handling *******************************/
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* function used to prevent loosing the open menu when using nested pulldowns,
* when moving mouse towards the pulldown menu over other buttons that could
* steal the highlight from the current button, only checks:
*
* - while mouse moves in triangular area defined old mouse position and
* left/right side of new menu
* - only for 1 second
*/
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
static void ui_mouse_motion_towards_init(uiHandleMenuData *menu, int mx, int my)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
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
if(!menu->dotowards) {
menu->dotowards= 1;
menu->towardsx= mx;
menu->towardsy= my;
menu->towardstime= PIL_check_seconds_timer();
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_mouse_motion_towards_check(uiBlock *block, uiHandleMenuData *menu, int mx, int my)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
int fac, dx, dy, domx, domy;
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
if(!menu->dotowards) return 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((block->direction & UI_TOP) || (block->direction & UI_DOWN)) {
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
menu->dotowards= 0;
return menu->dotowards;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
/* calculate dominant direction */
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
domx= (-menu->towardsx + (block->maxx+block->minx)/2);
domy= (-menu->towardsy + (block->maxy+block->miny)/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
/* we need some accuracy */
if(abs(domx) < 4) {
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
menu->dotowards= 0;
return menu->dotowards;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
/* check direction */
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
dx= mx - menu->towardsx;
dy= my - menu->towardsy;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/* threshold */
if(abs(dx)+abs(dy) > 4) {
/* menu to right */
if(domx>0) {
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
fac= (mx - menu->towardsx)*( menu->towardsy - (int)(block->maxy+20)) +
(my - menu->towardsy)*(-menu->towardsx + (int)block->minx);
if(fac>0) menu->dotowards= 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
fac= (mx - menu->towardsx)*( menu->towardsy - (int)(block->miny-20)) +
(my - menu->towardsy)*(-menu->towardsx + (int)block->minx);
if(fac<0) menu->dotowards= 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 {
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
fac= (mx - menu->towardsx)*( menu->towardsy - (int)(block->maxy+20)) +
(my - menu->towardsy)*(-menu->towardsx + (int)block->maxx);
if(fac<0) menu->dotowards= 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
fac= (mx - menu->towardsx)*( menu->towardsy - (int)(block->miny-20)) +
(my - menu->towardsy)*(-menu->towardsx + (int)block->maxx);
if(fac>0) menu->dotowards= 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
}
}
/* 1 second timer */
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
if(PIL_check_seconds_timer() - menu->towardstime > BUTTON_MOUSE_TOWARDS_THRESH)
menu->dotowards= 0;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
return menu->dotowards;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
int ui_handle_menu_event(bContext *C, wmEvent *event, uiHandleMenuData *menu, int topmenu)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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;
uiBut *but, *bt;
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
uiMenuBlockHandle *handle;
int inside, act, count, mx, my, retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
ar= menu->handle->region;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
block= ar->uiblocks.first;
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
handle= menu->handle;
2.5 Fix crashing in pop-up menus when click. There's something wrong still in handling menu itself, need Brecht too look at that... probably a wrong return value somewhere.
2008-12-03 15:49:41 +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
act= 0;
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
retval= WM_UI_HANDLER_CONTINUE;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
mx= event->x;
my= event->y;
ui_window_to_block(ar, block, &mx, &my);
/* check if mouse is inside block */
inside= 0;
if(block->minx <= mx && block->maxx >= mx)
if(block->miny <= my && block->maxy >= my)
inside= 1;
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
if(topmenu && event->type != TIMER) {
/* for ui_mouse_motion_towards_block */
if(event->type == MOUSEMOVE)
ui_mouse_motion_towards_init(menu, mx, my);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
switch(event->type) {
/* closing sublevels of pulldowns */
case LEFTARROWKEY:
if(event->val && (block->flag & UI_BLOCK_LOOP))
if(BLI_countlist(&block->saferct) > 0)
handle->menuretval= UI_RETURN_OUT;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
retval= WM_UI_HANDLER_BREAK;
break;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
/* opening sublevels of pulldowns */
case RIGHTARROWKEY:
if(event->val && (block->flag & UI_BLOCK_LOOP)) {
but= ui_but_find_activated(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
if(!but) {
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
/* no item active, we make first active */
if(block->direction & UI_TOP) but= ui_but_last(block);
else but= ui_but_first(block);
}
if(but && but->type==BLOCK)
ui_handle_button_activate(C, ar, but, BUTTON_ACTIVATE_OPEN);
}
retval= WM_UI_HANDLER_BREAK;
break;
case UPARROWKEY:
case DOWNARROWKEY:
case WHEELUPMOUSE:
case WHEELDOWNMOUSE:
/* arrowkeys: only handle for block_loop blocks */
if(inside || (block->flag & UI_BLOCK_LOOP)) {
if(event->val) {
but= ui_but_find_activated(ar);
if(but) {
if(ELEM(event->type, UPARROWKEY, WHEELUPMOUSE)) {
if(block->direction & UI_TOP) but= ui_but_next(but);
else but= ui_but_prev(but);
}
else {
if(block->direction & UI_TOP) but= ui_but_prev(but);
else but= ui_but_next(but);
}
if(but)
ui_handle_button_activate(C, ar, but, BUTTON_ACTIVATE);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if(!but) {
if(ELEM(event->type, UPARROWKEY, WHEELUPMOUSE)) {
if(block->direction & UI_TOP) bt= ui_but_first(block);
else bt= ui_but_last(block);
}
else {
if(block->direction & UI_TOP) bt= ui_but_last(block);
else bt= ui_but_first(block);
}
if(bt)
ui_handle_button_activate(C, ar, bt, BUTTON_ACTIVATE);
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
retval= WM_UI_HANDLER_BREAK;
break;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
UI: 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
case ONEKEY: case PAD1:
act= 1;
case TWOKEY: case PAD2:
if(act==0) act= 2;
case THREEKEY: case PAD3:
if(act==0) act= 3;
case FOURKEY: case PAD4:
if(act==0) act= 4;
case FIVEKEY: case PAD5:
if(act==0) act= 5;
case SIXKEY: case PAD6:
if(act==0) act= 6;
case SEVENKEY: case PAD7:
if(act==0) act= 7;
case EIGHTKEY: case PAD8:
if(act==0) act= 8;
case NINEKEY: case PAD9:
if(act==0) act= 9;
case ZEROKEY: case PAD0:
if(act==0) act= 10;
if(block->flag & UI_BLOCK_NUMSELECT) {
if(event->alt) act+= 10;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
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
count= 0;
for(but= block->buttons.first; but; but= but->next) {
int doit= 0;
if(but->type!=LABEL && but->type!=SEPR)
count++;
/* exception for menus like layer buts, with button aligning they're not drawn in order */
if(but->type==TOGR) {
if(but->bitnr==act-1)
doit= 1;
}
else if(count==act)
doit=1;
if(doit) {
ui_handle_button_activate(C, ar, but, BUTTON_ACTIVATE_APPLY);
break;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
UI: 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
retval= WM_UI_HANDLER_BREAK;
break;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
/* here we check return conditions for menus */
if(block->flag & UI_BLOCK_LOOP) {
/* if we click outside the block, verify if we clicked on the
* button that opened us, otherwise we need to close */
if(inside==0) {
uiSafetyRct *saferct= block->saferct.first;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if(ELEM3(event->type, LEFTMOUSE, MIDDLEMOUSE, RIGHTMOUSE) && event->val)
if(saferct && !BLI_in_rctf(&saferct->parent, event->x, event->y))
handle->menuretval= UI_RETURN_OK;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
if(handle->menuretval);
else if(event->type==ESCKEY && event->val) {
/* esc cancels this and all preceding menus */
handle->menuretval= UI_RETURN_CANCEL;
}
else if(ELEM(event->type, RETKEY, PADENTER) && event->val) {
/* enter will always close this block, but note that the event
* can still get pass through so the button is executed */
handle->menuretval= UI_RETURN_OK;
}
else {
ui_mouse_motion_towards_check(block, menu, mx, my);
/* check mouse moving outside of the menu */
if(inside==0 && (block->flag & UI_BLOCK_MOVEMOUSE_QUIT)) {
uiSafetyRct *saferct;
/* check for all parent rects, enables arrowkeys to be used */
for(saferct=block->saferct.first; saferct; saferct= saferct->next) {
/* for mouse move we only check our own rect, for other
* events we check all preceding block rects too to make
* arrow keys navigation work */
if(event->type!=MOUSEMOVE || saferct==block->saferct.first) {
if(BLI_in_rctf(&saferct->parent, (float)event->x, (float)event->y))
break;
if(BLI_in_rctf(&saferct->safety, (float)event->x, (float)event->y))
break;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
/* strict check, and include the parent rect */
if(!menu->dotowards && !saferct)
handle->menuretval= (block->flag & UI_BLOCK_KEEP_OPEN)? UI_RETURN_OK: UI_RETURN_OUT;
else if(menu->dotowards && event->type==MOUSEMOVE)
retval= WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
}
}
}
UI: 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
/* if we are inside the region and didn't handle the event yet, lets
* pass it on to buttons inside this region */
if((inside && !handle->menuretval && retval == WM_UI_HANDLER_CONTINUE) || event->type == TIMER) {
but= ui_but_find_activated(ar);
if(but)
retval= ui_handle_button_event(C, event, but);
else
retval= ui_handle_button_over(C, event, ar);
}
/* if we set a menu return value, ensure we continue passing this on to
* lower menus and buttons, so always set continue then, and if we are
* inside the region otherwise, ensure we swallow the event */
if(handle->menuretval)
return WM_UI_HANDLER_CONTINUE;
else if(inside)
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
else
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
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static int ui_handle_menu_closed_submenu(bContext *C, uiHandleMenuData *menu)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
ARegion *ar;
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
uiBlock *block;
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
uiHandleButtonData *data;
uiMenuBlockHandle *handle, *subhandle;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
ar= menu->handle->region;
block= ar->uiblocks.first;
handle= menu->handle;
but= ui_but_find_activated(ar);
data= but->active;
subhandle= data->menu->handle;
if(subhandle->menuretval) {
/* first decide if we want to close our own menu cascading, if
* so pass on the sub menu return value to our own menu handle */
if(ELEM(subhandle->menuretval, UI_RETURN_OK, UI_RETURN_CANCEL)) {
if(!(block->flag & UI_BLOCK_KEEP_OPEN)) {
handle->menuretval= subhandle->menuretval;
handle->butretval= data->retval;
}
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* now let activated button in this menu exit, which
* will actually close the submenu too */
ui_handle_button_closed_submenu(C, but);
}
if(handle->menuretval)
return WM_UI_HANDLER_CONTINUE;
else
return WM_UI_HANDLER_BREAK;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
UI: 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
static int ui_handle_menus_recursive(bContext *C, wmEvent *event, uiHandleMenuData *menu)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
uiBut *but;
uiHandleButtonData *data;
uiHandleMenuData *submenu;
int retval= WM_UI_HANDLER_CONTINUE;
/* check if we have a submenu, and handle events for it first */
but= ui_but_find_activated(menu->handle->region);
data= (but)? but->active: NULL;
submenu= (data)? data->menu: NULL;
if(submenu)
retval= ui_handle_menus_recursive(C, event, submenu);
/* now handle events for our own menu */
if(retval == WM_UI_HANDLER_CONTINUE || event->type == TIMER) {
if(submenu && submenu->handle->menuretval)
retval= ui_handle_menu_closed_submenu(C, menu);
else
retval= ui_handle_menu_event(C, event, menu, (submenu == NULL));
}
return retval;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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 event handlers **************** */
static int ui_handler_region(bContext *C, wmEvent *event)
{
ARegion *ar;
uiBut *but;
int retval;
/* here we handle buttons at the region level, non-modal */
ar= C->region;
retval= WM_UI_HANDLER_CONTINUE;
if(ar==NULL) return retval;
if(ar->uiblocks.first==NULL) return retval;
/* either handle events for already activated button or try to activate */
but= ui_but_find_activated(ar);
if(but)
retval= ui_handle_button_event(C, event, but);
else
retval= ui_handle_button_over(C, event, ar);
/* re-enable tooltips */
if(event->type == MOUSEMOVE && (event->x!=event->prevx || event->y!=event->prevy))
ui_blocks_set_tooltips(ar, 1);
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
/* delayed apply callbacks */
ui_apply_but_funcs_after(C);
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
return retval;
}
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
static void ui_handler_remove_region(bContext *C)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
{
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
ARegion *ar;
ar= C->region;
if(ar==NULL) return;
uiFreeBlocks(C, &ar->uiblocks);
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
/* delayed apply callbacks, but not for screen level regions, those
* we rather do at the very end after closing them all, which will
* be done in ui_handler_region/window */
if(BLI_findindex(&C->screen->regionbase, ar) == -1)
ui_apply_but_funcs_after(C);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
}
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
static int ui_handler_window(bContext *C, wmEvent *event)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
ARegion *ar;
uiBut *but;
uiHandleButtonData *data;
int retval;
/* here we handle buttons at the window level, modal, for example
* while number sliding, text editing, or when a menu block is open */
ar= C->region;
/* handle activated button events */
but= ui_but_find_activated(ar);
if(but) {
data= but->active;
if(data->state == BUTTON_STATE_MENU_OPEN) {
/* handle events for menus and their buttons recursively,
* this will handle events from the top to the bottom menu */
retval= ui_handle_menus_recursive(C, event, data->menu);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. 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
/* handle events for the activated button */
if(retval == WM_UI_HANDLER_CONTINUE || event->type == TIMER) {
if(data->menu->handle->menuretval)
ui_handle_button_closed_submenu(C, but);
else
ui_handle_button_event(C, event, but);
}
}
else {
/* handle events for the activated button */
ui_handle_button_event(C, event, but);
}
}
/* re-enable tooltips */
if(event->type == MOUSEMOVE && (event->x!=event->prevx || event->y!=event->prevy))
ui_blocks_set_tooltips(ar, 1);
UI: restored mechanism to only call button/block callback functions after the menus are closed, to avoid conflicts with those callbacks manipulating their own area or region.
2008-12-11 20:30:41 +00:00
/* delayed apply callbacks */
ui_apply_but_funcs_after(C);
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
/* we block all events, this is modal interaction */
return WM_UI_HANDLER_BREAK;
}
void UI_add_region_handlers(ListBase *handlers)
{
WM_event_remove_ui_handler(handlers);
WM_event_add_ui_handler(NULL, handlers, ui_handler_region, ui_handler_remove_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
}
Copy Permalink