Files
test2/source/blender/editors/include/UI_view2d.hh

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

588 lines
20 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2008 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** \file
* \ingroup editorui
* Generic 2D view with should allow drawing grids,
* panning, zooming, scrolling, .. etc.
2011-02-21 07:25:24 +00:00
*/
#pragma once
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
#include "BLI_compiler_attrs.h"
#include "BLI_rect.h"
/* -------------------------------------------------------------------- */
/** \name General Defines
* \{ */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** Generic value to use when coordinate lies out of view when converting. */
#define V2D_IS_CLIPPED 12000
/**
* Common View2D view types.
*
* \note only define a type here if it completely sets all (+/- a few) of the relevant flags and
* settings for a View2D region, and that set of settings is used in more than one specific place.
*/
enum eView2D_CommonViewTypes {
/** custom view type (region has defined all necessary flags already). */
V2D_COMMONVIEW_CUSTOM = -1,
/** standard (only use this when setting up a new view, as a sensible base for most settings). */
V2D_COMMONVIEW_STANDARD,
/** List-view (i.e. Outliner). */
V2D_COMMONVIEW_LIST,
/** Stack-view (this is basically a list where new items are added at the top). */
V2D_COMMONVIEW_STACK,
/** headers (this is basically the same as list-view, but no Y-panning). */
V2D_COMMONVIEW_HEADER,
/** UI region containing panels. */
V2D_COMMONVIEW_PANELS_UI,
};
/** \} */
/* -------------------------------------------------------------------- */
/** \name Defines for Scroll Bars
* \{ */
/** Scroll bar area. */
/* Maximum has to include outline which varies with line width. */
#define V2D_SCROLL_HEIGHT ((0.45f * U.widget_unit) + (2.0f * U.pixelsize))
#define V2D_SCROLL_WIDTH ((0.45f * U.widget_unit) + (2.0f * U.pixelsize))
2022-09-19 14:47:27 +10:00
/* Alpha of scroll-bar when at minimum size. */
#define V2D_SCROLL_MIN_ALPHA (0.4f)
/* Minimum size needs to include outline which varies with line width. */
#define V2D_SCROLL_MIN_WIDTH ((5.0f * UI_SCALE_FAC) + (2.0f * U.pixelsize))
/* When to start showing the full-width scroller. */
#define V2D_SCROLL_HIDE_WIDTH (AREAMINX * UI_SCALE_FAC)
#define V2D_SCROLL_HIDE_HEIGHT (HEADERY * UI_SCALE_FAC)
/** Scroll bars with 'handles' used for scale (zoom). */
#define V2D_SCROLL_HANDLE_HEIGHT (0.6f * U.widget_unit)
#define V2D_SCROLL_HANDLE_WIDTH (0.6f * U.widget_unit)
/** Scroll bar with 'handles' hot-spot radius for cursor proximity. */
#define V2D_SCROLL_HANDLE_SIZE_HOTSPOT (0.6f * U.widget_unit)
/** Don't allow scroll thumb to show below this size (so it's never too small to click on). */
#define V2D_SCROLL_THUMB_SIZE_MIN (30.0 * UI_SCALE_FAC)
/** \} */
/* -------------------------------------------------------------------- */
/** \name Define for #UI_view2d_sync
* \{ */
/* means copy it from another v2d */
#define V2D_LOCK_SET 0
/* means copy it to the other v2ds */
#define V2D_LOCK_COPY 1
/** \} */
/* -------------------------------------------------------------------- */
/** \name Macros
* \{ */
2022-09-19 14:47:27 +10:00
/* Test if mouse in a scroll-bar (assume that scroller availability has been tested). */
#define IN_2D_VERT_SCROLL(v2d, co) (BLI_rcti_isect_pt_v(&v2d->vert, co))
#define IN_2D_HORIZ_SCROLL(v2d, co) (BLI_rcti_isect_pt_v(&v2d->hor, co))
#define IN_2D_VERT_SCROLL_RECT(v2d, rct) (BLI_rcti_isect(&v2d->vert, rct, NULL))
#define IN_2D_HORIZ_SCROLL_RECT(v2d, rct) (BLI_rcti_isect(&v2d->hor, rct, NULL))
/** \} */
/* -------------------------------------------------------------------- */
2022-10-10 11:21:53 +11:00
/** \name Forward Declarations
* \{ */
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
struct View2D;
struct View2DScrollers;
struct ARegion;
struct Scene;
struct ScrArea;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
struct bContext;
struct bScreen;
struct rctf;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
struct rcti;
struct wmEvent;
struct wmGizmoGroupType;
struct wmKeyConfig;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
struct wmOperator;
struct wmOperatorType;
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Prototypes
* \{ */
/**
* Refresh and validation (of view rects).
*
* Initialize all relevant View2D data (including view rects if first time)
* and/or refresh mask sizes after view resize.
*
* - For some of these presets, it is expected that the region will have defined some
* additional settings necessary for the customization of the 2D viewport to its requirements
* - This function should only be called from region init() callbacks, where it is expected that
* this is called before #UI_view2d_size_update(),
* as this one checks that the rects are properly initialized.
*/
void UI_view2d_region_reinit(View2D *v2d, short type, int winx, int winy);
void UI_view2d_curRect_validate(View2D *v2d);
/**
* Restore 'cur' rect to standard orientation (i.e. optimal maximum view of tot).
* This does not take into account if zooming the view on an axis
* will improve the view (if allowed).
*/
void UI_view2d_curRect_reset(View2D *v2d);
bool UI_view2d_area_supports_sync(ScrArea *area);
/**
* Called by menus to activate it, or by view2d operators
* to make sure 'related' views stay in synchrony.
*/
void UI_view2d_sync(bScreen *screen, ScrArea *area, View2D *v2dcur, int flag);
/**
* Perform all required updates after `v2d->cur` as been modified.
2020-08-17 12:34:05 +10:00
* This includes like validation view validation (#UI_view2d_curRect_validate).
*
* Current intent is to use it from user code, such as view navigation and zoom operations.
*/
void UI_view2d_curRect_changed(const bContext *C, View2D *v2d);
void UI_view2d_totRect_set(View2D *v2d, int width, int height);
void UI_view2d_mask_from_win(const View2D *v2d, rcti *r_mask);
2018-10-22 16:41:18 +11:00
void UI_view2d_zoom_cache_reset();
/**
* Clamp view2d area to what's visible, preventing
* scrolling vertically to infinity.
*/
void UI_view2d_curRect_clamp_y(View2D *v2d);
/** \} */
/* -------------------------------------------------------------------- */
/** \name View Matrix Operations
* \{ */
/**
* Set view matrices to use 'cur' rect as viewing frame for View2D drawing.
*/
void UI_view2d_view_ortho(const View2D *v2d);
/**
* Set view matrices to only use one axis of 'cur' only
*
* \param xaxis: if non-zero, only use cur x-axis,
* otherwise use cur-yaxis (mostly this will be used for x).
*/
void UI_view2d_view_orthoSpecial(ARegion *region, View2D *v2d, bool xaxis);
/**
* Restore view matrices after drawing.
*/
void UI_view2d_view_restore(const bContext *C);
/** \} */
/* -------------------------------------------------------------------- */
/** \name Grid Drawing
* \{ */
/**
* Draw a multi-level grid in given 2d-region.
*/
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
void UI_view2d_multi_grid_draw(
const View2D *v2d, int colorid, float step, int level_size, int totlevels);
/**
* Draw a multi-level grid of dots, with a dynamic number of levels based on the fading.
*
* \param grid_color_id: The theme color used for the points. Faded dynamically based on zoom.
* \param min_step: The base size of the grid. At different zoom levels, the visible grid may have
* a larger step size.
* \param grid_subdivisions: The maximum number of sub-levels drawn at once.
*/
void UI_view2d_dot_grid_draw(const View2D *v2d,
int grid_color_id,
float min_step,
int grid_subdivisions);
void UI_view2d_draw_lines_y__values(const View2D *v2d);
void UI_view2d_draw_lines_x__values(const View2D *v2d);
void UI_view2d_draw_lines_x__discrete_values(const View2D *v2d, bool display_minor_lines);
void UI_view2d_draw_lines_x__discrete_time(const View2D *v2d,
const Scene *scene,
bool display_minor_lines);
void UI_view2d_draw_lines_x__discrete_frames_or_seconds(const View2D *v2d,
const Scene *scene,
bool display_seconds,
bool display_minor_lines);
void UI_view2d_draw_lines_x__frames_or_seconds(const View2D *v2d,
const Scene *scene,
bool display_seconds);
float UI_view2d_grid_resolution_x__frames_or_seconds(const View2D *v2d,
const Scene *scene,
bool display_seconds);
float UI_view2d_grid_resolution_y__values(const View2D *v2d);
/**
* Scale indicator text drawing.
*/
void UI_view2d_draw_scale_y__values(const ARegion *region,
const View2D *v2d,
const rcti *rect,
int colorid);
void UI_view2d_draw_scale_y__block(const ARegion *region,
const View2D *v2d,
const rcti *rect,
int colorid);
void UI_view2d_draw_scale_x__discrete_frames_or_seconds(const ARegion *region,
const View2D *v2d,
const rcti *rect,
const Scene *scene,
bool display_seconds,
int colorid);
void UI_view2d_draw_scale_x__frames_or_seconds(const ARegion *region,
const View2D *v2d,
const rcti *rect,
const Scene *scene,
bool display_seconds,
int colorid);
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Scroll-bar Drawing
* \{ */
/**
* Draw scroll-bars in the given 2D-region.
*/
void UI_view2d_scrollers_draw_ex(View2D *v2d, const rcti *mask_custom, bool use_full_hide);
void UI_view2d_scrollers_draw(View2D *v2d, const rcti *mask_custom);
/** \} */
/* -------------------------------------------------------------------- */
/** \name List View Tools
* \{ */
/**
* Get the 'cell' (row, column) that the given 2D-view coordinates
* (i.e. in 'tot' rect space) lie in.
*
* \param columnwidth, rowheight: size of each 'cell'
* \param startx, starty: coordinates (in 'tot' rect space) that the list starts from.
* This should be (0,0) for most views. However, for those where the starting row was offsetted
* (like for Animation Editor channel lists, to make the first entry more visible), these will be
* the min-coordinates of the first item.
* \param viewx, viewy: 2D-coordinates (in 2D-view / 'tot' rect space) to get the cell for
* \param r_column, r_row: The 'coordinates' of the relevant 'cell'.
*/
void UI_view2d_listview_view_to_cell(float columnwidth,
float rowheight,
float startx,
float starty,
float viewx,
float viewy,
int *r_column,
int *r_row);
/** \} */
/* -------------------------------------------------------------------- */
/** \name Coordinate Conversion
* \{ */
float UI_view2d_region_to_view_x(const View2D *v2d, float x);
float UI_view2d_region_to_view_y(const View2D *v2d, float y);
/**
* Convert from screen/region space to 2d-View space
*
* \param x, y: coordinates to convert
* \param r_view_x, r_view_y: resultant coordinates
*/
2018-11-13 13:28:43 +11:00
void UI_view2d_region_to_view(
const View2D *v2d, float x, float y, float *r_view_x, float *r_view_y) ATTR_NONNULL();
void UI_view2d_region_to_view_rctf(const View2D *v2d, const rctf *rect_src, rctf *rect_dst)
ATTR_NONNULL();
2018-11-13 13:28:43 +11:00
float UI_view2d_view_to_region_x(const View2D *v2d, float x);
float UI_view2d_view_to_region_y(const View2D *v2d, float y);
/**
* Convert from 2d-View space to screen/region space
* \note Coordinates are clamped to lie within bounds of region
*
* \param x, y: Coordinates to convert.
* \param r_region_x, r_region_y: Resultant coordinates.
*/
2018-11-13 13:28:43 +11:00
bool UI_view2d_view_to_region_clip(
const View2D *v2d, float x, float y, int *r_region_x, int *r_region_y) ATTR_NONNULL();
bool UI_view2d_view_to_region_segment_clip(const View2D *v2d,
const float xy_a[2],
const float xy_b[2],
int r_region_a[2],
int r_region_b[2]) ATTR_NONNULL();
/**
* Convert from 2d-view space to screen/region space
*
* \note Coordinates are NOT clamped to lie within bounds of region.
*
* \param x, y: Coordinates to convert.
* \param r_region_x, r_region_y: Resultant coordinates.
*/
void UI_view2d_view_to_region(
const View2D *v2d, float x, float y, int *r_region_x, int *r_region_y) ATTR_NONNULL();
void UI_view2d_view_to_region_fl(
const View2D *v2d, float x, float y, float *r_region_x, float *r_region_y) ATTR_NONNULL();
void UI_view2d_view_to_region_m4(const View2D *v2d, float matrix[4][4]) ATTR_NONNULL();
void UI_view2d_view_to_region_rcti(const View2D *v2d, const rctf *rect_src, rcti *rect_dst)
ATTR_NONNULL();
bool UI_view2d_view_to_region_rcti_clip(const View2D *v2d, const rctf *rect_src, rcti *rect_dst)
ATTR_NONNULL();
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Utilities
* \{ */
/**
* View2D data by default resides in region, so get from region stored in context.
*/
View2D *UI_view2d_fromcontext(const bContext *C);
/**
* Same as above, but it returns region-window. Utility for pull-downs or buttons.
*/
View2D *UI_view2d_fromcontext_rwin(const bContext *C);
/**
2022-09-19 14:47:27 +10:00
* Get scroll-bar sizes of the current 2D view.
* The size will be zero if the view has its scroll-bars disabled.
*
* \param mapped: whether to use view2d_scroll_mapped which changes flags
*/
void UI_view2d_scroller_size_get(const View2D *v2d, bool mapped, float *r_x, float *r_y);
/**
* Calculate the scale per-axis of the drawing-area
*
* Is used to inverse correct drawing of icons, etc. that need to follow view
* but not be affected by scale
*
* \param r_x, r_y: scale on each axis
*/
void UI_view2d_scale_get(const View2D *v2d, float *r_x, float *r_y);
float UI_view2d_scale_get_x(const View2D *v2d);
float UI_view2d_scale_get_y(const View2D *v2d);
/**
* Same as `UI_view2d_scale_get() - 1.0f / x, y`.
*/
void UI_view2d_scale_get_inverse(const View2D *v2d, float *r_x, float *r_y);
/**
* Simple functions for consistent center offset access.
* Used by node editor to shift view center for each individual node tree.
*/
void UI_view2d_center_get(const View2D *v2d, float *r_x, float *r_y);
void UI_view2d_center_set(View2D *v2d, float x, float y);
Merge of the PyNodes branch (aka "custom nodes") into trunk. PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements. === Dynamic node type registration === Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes. Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2]. === Node group improvements === Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3]. The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there. [1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes [2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender [3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
2013-03-18 16:34:57 +00:00
/**
* Simple pan function
* (0.0, 0.0) bottom left
* (0.5, 0.5) center
* (1.0, 1.0) top right.
*/
void UI_view2d_offset(View2D *v2d, float xfac, float yfac);
/**
* Scrolls the view so that the upper edge is at a multiple of the page size.
*/
void UI_view2d_offset_y_snap_to_closest_page(View2D *v2d);
/**
* Check if mouse is within scrollers
*
* \param xy: Mouse coordinates in screen (not region) space.
* \param r_scroll: Return argument for the mapped view2d scroll flag.
*
* \return appropriate code for match.
* - 'h' = in horizontal scroller.
* - 'v' = in vertical scroller.
* - 0 = not in scroller.
*/
char UI_view2d_mouse_in_scrollers_ex(const ARegion *region,
const View2D *v2d,
const int xy[2],
int *r_scroll) ATTR_NONNULL(1, 2, 3, 4);
char UI_view2d_mouse_in_scrollers(const ARegion *region, const View2D *v2d, const int xy[2])
ATTR_NONNULL(1, 2, 3);
char UI_view2d_rect_in_scrollers_ex(const ARegion *region,
const View2D *v2d,
const rcti *rect,
int *r_scroll) ATTR_NONNULL(1, 2, 3);
char UI_view2d_rect_in_scrollers(const ARegion *region, const View2D *v2d, const rcti *rect)
ATTR_NONNULL(1, 2, 3);
/**
* Cached text drawing in v2d, to allow pixel-aligned draw as post process.
*/
void UI_view2d_text_cache_add(
View2D *v2d, float x, float y, const char *str, size_t str_len, const unsigned char col[4]);
/**
* No clip (yet).
*/
void UI_view2d_text_cache_add_rectf(View2D *v2d,
const rctf *rect_view,
2014-04-21 18:46:52 +10:00
const char *str,
size_t str_len,
const unsigned char col[4]);
void UI_view2d_text_cache_draw(ARegion *region);
/** \} */
/* -------------------------------------------------------------------- */
/** \name Operators
* \{ */
void ED_operatortypes_view2d();
void ED_keymap_view2d(wmKeyConfig *keyconf);
/**
* Will start timer if appropriate.
* the arguments are the desired situation.
*/
void UI_view2d_smooth_view(const bContext *C, ARegion *region, const rctf *cur, int smooth_viewtx);
#define UI_MARKER_MARGIN_Y (42 * UI_SCALE_FAC)
#define UI_TIME_SCRUB_MARGIN_Y (23 * UI_SCALE_FAC)
Port of part of the Interface code to 2.50. This is based on the current trunk version, so these files should not need merges. There's two things (clipboard and intptr_t) that are missing in 2.50 and commented out with XXX 2.48, these can be enabled again once trunk is merged into this branch. Further this is not all interface code, there are many parts commented out: * interface.c: nearly all button types, missing: links, chartab, keyevent. * interface_draw.c: almost all code, with some small exceptions. * interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators, making it non-blocking. * interface_regions: this is a part of interface.c, split off, contains code to create regions for tooltips, menus, pupmenu (that one is crashing currently), color chooser, basically regions with buttons which is fairly independent of core interface code. * interface_panel.c and interface_icons.c: not ported over, so no panels and icons yet. Panels should probably become (free floating) regions? * text.c: (formerly language.c) for drawing text and translation. this works but is using bad globals still and could be cleaned up. Header Files: * ED_datafiles.h now has declarations for datatoc_ files, so those extern declarations can be #included instead of repeated. * The user interface code is in UI_interface.h and other UI_* files. Core: * The API for creating blocks, buttons, etc is nearly the same still. Blocks are now created per region instead of per area. * The code was made non-blocking, which means that any changes and redraws should be possible while editing a button. That means though that we need some sort of persistence even though the blender model is to recreate buttons for each redraw. So when a new block is created, some matching happens to find out which buttons correspond to buttons in the previously created block, and for activated buttons some data is then copied over to the new button. * Added UI_init/UI_init_userdef/UI_exit functions that should initialize code in this module, instead of multiple function calls in the windowmanager. * Removed most static/globals from interface.c. * Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it would integrate here? * Currently only full window redraws are used, this should become per region and maybe per button later. Operators: * Events are currently handled through two operators: button activate and menu handle. Operators may not be the best way to implement this, since there are currently some issues with events being missed, but they can become a special handler type instead, this should not be a big change. * The button activate operator runs as long as a button is active, and will handle all interaction with that button until the button is not activated anymore. This means clicking, text editing, number dragging, opening menu blocks, etc. * Since this operator has to be non-blocking, the ui_do_but code needed to made non-blocking. That means variables that were previously on the stack, now need to be stored away in a struct such that they can be accessed again when the operator receives more events. * Additionally the place in the ui_do_but code indicated the state, now that needs to be set explicit in order to handle the right events in the right state. So an activated button can be in one of these states: init, highlight, wait_flash, wait_release, wait_key_event, num_editing, text_editing, text_selecting, block_open, exit. * For each button type an ui_apply_but_* function has also been separated out from ui_do_but. This makes it possible to continuously apply the button as text is being typed for example, and there is an option in the code to enable this. Since the code non-blocking and can deal with the button being deleted even, it should be safe to do this. * When editing text, dragging numbers, etc, the actual data (but->poin) is not being edited, since that would mean data is being edited without correct updates happening, while some other part of blender may be accessing that data in the meantime. So data values, strings, vectors are written to a temporary location and only flush in the apply function. Regions: * Menus, color chooser, tooltips etc all create screen level regions. Such menu blocks give a handle to the button that creates it, which will contain the results of the menu block once a MESSAGE event is received from that menu block. * For this type of menu block the coordinates used to be in window space. They are still created that way and ui_positionblock still works with window coordinates, but after that the block and buttons are brought back to region coordinates since these are now contained in a region. * The flush/overdraw frontbuffer drawing code was removed, the windowmanager should have enough information with these screen level regions to have full control over what gets drawn when and to then do correct compositing. Testing: * The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
/** \} */
/* -------------------------------------------------------------------- */
/** \name Gizmo Types
* \{ */
/* `view2d_gizmo_navigate.cc` */
/**
* Caller defines the name for gizmo group.
*/
void VIEW2D_GGT_navigate_impl(wmGizmoGroupType *gzgt, const char *idname);
/** \} */
/* -------------------------------------------------------------------- */
/** \name Edge Pan
* \{ */
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/**
* Custom-data for view panning operators.
*/
struct View2DEdgePanData {
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Screen where view pan was initiated. */
bScreen *screen;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Area where view pan was initiated. */
ScrArea *area;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Region where view pan was initiated. */
ARegion *region;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** View2d we're operating in. */
View2D *v2d;
2022-04-05 07:39:40 +10:00
/** Limit maximum pannable area. */
struct rctf limit;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Panning should only start once being in the inside rect once (e.g. adding nodes can happen
* outside). */
bool enabled;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Inside distance in UI units from the edge of the region within which to start panning. */
float inside_pad;
/** Outside distance in UI units from the edge of the region at which to stop panning. */
float outside_pad;
/**
* Width of the zone in UI units where speed increases with distance from the edge.
* At the end of this zone max speed is reached.
*/
float speed_ramp;
/** Maximum speed in UI units per second. */
float max_speed;
/** Delay in seconds before maximum speed is reached. */
float delay;
/**
* Influence factor for view zoom:
* - 0 = Constant speed in UI units.
* - 1 = Constant speed in view space, UI speed slows down when zooming out.
*/
float zoom_influence;
/** Initial view rect. */
rctf initial_rect;
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** Amount to move view relative to zoom. */
float facx, facy;
/* Timers. */
double edge_pan_last_time;
double edge_pan_start_time_x, edge_pan_start_time_y;
};
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
void UI_view2d_edge_pan_init(bContext *C,
View2DEdgePanData *vpd,
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
float inside_pad,
float outside_pad,
float speed_ramp,
float max_speed,
float delay,
float zoom_influence);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/**
* Set area which can be panned
*/
void UI_view2d_edge_pan_set_limits(
View2DEdgePanData *vpd, float xmin, float xmax, float ymin, float ymax);
void UI_view2d_edge_pan_reset(View2DEdgePanData *vpd);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/**
* Apply transform to view (i.e. adjust 'cur' rect).
*/
void UI_view2d_edge_pan_apply(bContext *C, View2DEdgePanData *vpd, const int xy[2])
ATTR_NONNULL(1, 2, 3);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/**
* Apply transform to view using mouse events.
*/
void UI_view2d_edge_pan_apply_event(bContext *C, View2DEdgePanData *vpd, const wmEvent *event);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
void UI_view2d_edge_pan_cancel(bContext *C, View2DEdgePanData *vpd);
void UI_view2d_edge_pan_operator_properties(wmOperatorType *ot);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
void UI_view2d_edge_pan_operator_properties_ex(wmOperatorType *ot,
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
float inside_pad,
float outside_pad,
float speed_ramp,
float max_speed,
float delay,
float zoom_influence);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/**
* Initialize panning data with operator settings.
*/
void UI_view2d_edge_pan_operator_init(bContext *C, View2DEdgePanData *vpd, wmOperator *op);
Edge-scrolling for node editor Starts scrolling when dragging a node or node link and going outside the current window. Largely copied from the VIEW2D_OT_edge_pan operator. Edge panning operator customdata and supporting functions now in UI_view2d.h, so they could be used by operators in other editor libraries. The VIEW2D_OT_edge_pan operator also uses this customdata and shared functions now. Operators properties can be used to configure edge panning margins and speed for each use case, rather than using hardcoded values. The speed function for edge panning has been tweaked somewhat: * "Speed per pixel" has been replaced with a "speed ramp" distance. This is more intuitive and also creates an upper bound for the speed, which can otherwise become extreme with large cursor distance. * "Max speed" is reached at the end of the speed ramp. * Padding the region inside and outside is applied as before, but both values are operator properties now. Node transform operator also supports edge panning. This requires an offset for changes in the view2d rect, otherwise nodes are "stuck" to the original view. Transform operator had cursor wrapping categorically enabled, but this gets quite confusing with the edge scrolling mechanism. A new TransInfo option T_NO_CURSOR_WRAP has been introduced to disable this behavior. The double negative is a bit annoying, but want to avoid affecting the existing transform modes, so by default it should still set the OP_IS_MODAL_GRAB_CURSOR flag (which then sets the WM_CURSOR_WRAP_XY flag during modal execution). Reviewed By: HooglyBoogly, JacquesLucke Differential Revision: https://developer.blender.org/D11073
2021-06-16 18:17:07 +01:00
/** \} */