2011-02-21 07:25:24 +00:00
|
|
|
/*
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
|
* All rights reserved.
|
2008-11-28 04:01:35 +00:00
|
|
|
* Generic 2d view with should allow drawing grids,
|
2018-06-01 18:19:39 +02:00
|
|
|
* panning, zooming, scrolling, ..
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
*/
|
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup editorui
|
2011-02-21 07:25:24 +00:00
|
|
|
*/
|
|
|
|
|
|
2012-02-17 18:59:41 +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
|
|
|
|
2014-04-21 16:47:16 +10:00
|
|
|
#include "BLI_compiler_attrs.h"
|
|
|
|
|
|
2020-03-02 15:09:10 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2008-11-28 04:01:35 +00:00
|
|
|
/* ------------------------------------------ */
|
2012-05-12 20:39:39 +00:00
|
|
|
/* Settings and 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
|
|
|
|
2008-12-15 11:58:57 +00:00
|
|
|
/* ---- General Defines ---- */
|
|
|
|
|
|
2008-11-30 06:15:33 +00:00
|
|
|
/* generic value to use when coordinate lies out of view when converting */
|
2012-05-12 20:39:39 +00:00
|
|
|
#define V2D_IS_CLIPPED 12000
|
2008-11-30 06:15:33 +00:00
|
|
|
|
2018-06-04 09:31:30 +02:00
|
|
|
/* Common View2D view types
|
2018-06-01 18:19:39 +02:00
|
|
|
* NOTE: only define a type here if it completely sets all (+/- a few) of the relevant flags
|
2018-11-14 12:53:15 +11:00
|
|
|
* and settings for a View2D region, and that set of settings is used in more
|
|
|
|
|
* than one specific place
|
2008-12-17 10:25:02 +00:00
|
|
|
*/
|
2013-03-22 05:46:39 +00:00
|
|
|
enum eView2D_CommonViewTypes {
|
2012-05-12 20:39:39 +00:00
|
|
|
/* custom view type (region has defined all necessary flags already) */
|
2008-12-17 10:25:02 +00:00
|
|
|
V2D_COMMONVIEW_CUSTOM = -1,
|
2012-05-12 20:39:39 +00:00
|
|
|
/* standard (only use this when setting up a new view, as a sensible base for most settings) */
|
2008-12-17 10:25:02 +00:00
|
|
|
V2D_COMMONVIEW_STANDARD,
|
2012-05-12 20:39:39 +00:00
|
|
|
/* listview (i.e. Outliner) */
|
2008-12-15 11:58:57 +00:00
|
|
|
V2D_COMMONVIEW_LIST,
|
2012-05-12 20:39:39 +00:00
|
|
|
/* stackview (this is basically a list where new items are added at the top) */
|
2009-05-29 12:26:47 +00:00
|
|
|
V2D_COMMONVIEW_STACK,
|
2012-05-12 20:39:39 +00:00
|
|
|
/* headers (this is basically the same as listview, but no y-panning) */
|
2008-12-15 11:58:57 +00:00
|
|
|
V2D_COMMONVIEW_HEADER,
|
2012-05-12 20:39:39 +00:00
|
|
|
/* ui region containing panels */
|
2019-02-03 14:01:45 +11:00
|
|
|
V2D_COMMONVIEW_PANELS_UI,
|
2013-03-22 05:46:39 +00:00
|
|
|
};
|
2008-12-07 06:21:06 +00:00
|
|
|
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
/* ---- Defines for Scroller Arguments ----- */
|
2008-12-15 11:58:57 +00:00
|
|
|
|
|
|
|
|
/* ------ Defines for Scrollers ----- */
|
|
|
|
|
|
2019-06-04 10:53:12 +10:00
|
|
|
/** Scroll bar area. */
|
2018-04-27 00:49:00 +02:00
|
|
|
#define V2D_SCROLL_HEIGHT (0.45f * U.widget_unit)
|
|
|
|
|
#define V2D_SCROLL_WIDTH (0.45f * U.widget_unit)
|
2019-06-04 10:53:12 +10:00
|
|
|
/** 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)
|
2008-12-15 11:58:57 +00:00
|
|
|
|
2019-06-04 10:53:12 +10:00
|
|
|
/** Scroll bar with 'handles' hot-spot radius for cursor proximity. */
|
|
|
|
|
#define V2D_SCROLL_HANDLE_SIZE_HOTSPOT (0.6f * U.widget_unit)
|
2008-11-30 06:15:33 +00:00
|
|
|
|
2019-06-04 10:53:12 +10:00
|
|
|
/** Don't allow scroll thumb to show below this size (so it's never too small to click on). */
|
2019-07-05 09:43:13 +02:00
|
|
|
#define V2D_SCROLL_THUMB_SIZE_MIN (30.0 * UI_DPI_FAC)
|
2019-06-03 18:13:52 +02:00
|
|
|
|
2008-12-15 18:09:55 +00:00
|
|
|
/* ------ Define for UI_view2d_sync ----- */
|
|
|
|
|
|
2008-12-16 12:28:00 +00:00
|
|
|
/* means copy it from another v2d */
|
2012-05-12 20:39:39 +00:00
|
|
|
#define V2D_LOCK_SET 0
|
2008-12-16 12:28:00 +00:00
|
|
|
/* means copy it to the other v2ds */
|
2012-05-12 20:39:39 +00:00
|
|
|
#define V2D_LOCK_COPY 1
|
2008-12-15 18:09:55 +00:00
|
|
|
|
2008-11-28 04:01:35 +00:00
|
|
|
/* ------------------------------------------ */
|
2018-11-14 12:53:15 +11:00
|
|
|
/* Macros: */
|
2008-11-28 04:01:35 +00:00
|
|
|
|
2008-12-15 11:58:57 +00:00
|
|
|
/* test if mouse in a scrollbar (assume that scroller availability has been tested) */
|
2012-08-23 18:25:45 +00:00
|
|
|
#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))
|
2008-11-28 04:01:35 +00:00
|
|
|
|
2019-04-23 16:43:50 +10:00
|
|
|
#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))
|
|
|
|
|
|
2008-11-28 04:01:35 +00:00
|
|
|
/* ------------------------------------------ */
|
2012-05-12 20:39:39 +00:00
|
|
|
/* Type definitions: */
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
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;
|
2008-11-30 06:15:33 +00:00
|
|
|
struct View2DScrollers;
|
|
|
|
|
|
2019-01-28 21:08:24 +11:00
|
|
|
struct ARegion;
|
2012-12-14 08:05:56 +00:00
|
|
|
struct Scene;
|
2008-12-21 11:56:42 +00:00
|
|
|
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;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct bScreen;
|
2009-01-02 00:56:48 +00:00
|
|
|
struct rctf;
|
2021-06-16 18:17:07 +01:00
|
|
|
struct rcti;
|
|
|
|
|
struct wmEvent;
|
2019-05-31 21:45:28 +10:00
|
|
|
struct wmGizmoGroupType;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct wmKeyConfig;
|
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
|
|
|
|
2008-11-30 06:15:33 +00:00
|
|
|
typedef struct View2DScrollers View2DScrollers;
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
|
2008-11-28 04:01:35 +00:00
|
|
|
/* ----------------------------------------- */
|
2012-05-12 20:39:39 +00:00
|
|
|
/* Prototypes: */
|
2008-11-28 04:01:35 +00:00
|
|
|
|
2008-12-05 02:03:37 +00:00
|
|
|
/* refresh and validation (of view rects) */
|
2008-12-16 11:24:24 +00:00
|
|
|
void UI_view2d_region_reinit(struct View2D *v2d, short type, int winx, int winy);
|
2008-12-15 11:58:57 +00:00
|
|
|
|
2008-12-10 09:07:15 +00:00
|
|
|
void UI_view2d_curRect_validate(struct View2D *v2d);
|
2008-12-05 02:03:37 +00:00
|
|
|
void UI_view2d_curRect_reset(struct View2D *v2d);
|
2020-04-03 13:25:03 +02:00
|
|
|
void UI_view2d_sync(struct bScreen *screen, struct ScrArea *area, struct View2D *v2dcur, int flag);
|
2008-12-15 11:58:57 +00:00
|
|
|
|
2020-08-12 12:36:19 +02:00
|
|
|
/* 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).
|
2020-08-12 12:36:19 +02:00
|
|
|
*
|
2020-08-17 12:34:05 +10:00
|
|
|
* Current intent is to use it from user code, such as view navigation and zoom operations. */
|
2020-08-12 12:36:19 +02:00
|
|
|
void UI_view2d_curRect_changed(const struct bContext *C, struct View2D *v2d);
|
|
|
|
|
|
2008-12-10 09:07:15 +00:00
|
|
|
void UI_view2d_totRect_set(struct View2D *v2d, int width, int height);
|
2015-10-17 01:01:57 +11:00
|
|
|
void UI_view2d_totRect_set_resize(struct View2D *v2d, int width, int height, bool resize);
|
2009-07-29 22:57:53 +00:00
|
|
|
|
2018-10-22 16:41:18 +11:00
|
|
|
void UI_view2d_mask_from_win(const struct View2D *v2d, struct rcti *r_mask);
|
|
|
|
|
|
2014-01-20 12:43:56 +11:00
|
|
|
void UI_view2d_zoom_cache_reset(void);
|
|
|
|
|
|
2008-12-05 02:03:37 +00:00
|
|
|
/* view matrix operations */
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
void UI_view2d_view_ortho(const struct View2D *v2d);
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_view_orthoSpecial(struct ARegion *region, struct View2D *v2d, const bool xaxis);
|
2008-12-01 00:20:19 +00:00
|
|
|
void UI_view2d_view_restore(const struct bContext *C);
|
|
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
/* grid drawing */
|
2020-05-04 19:32:59 +10:00
|
|
|
void UI_view2d_constant_grid_draw(const struct View2D *v2d, float step);
|
2013-03-18 16:34:57 +00:00
|
|
|
void UI_view2d_multi_grid_draw(
|
2020-05-04 19:32:59 +10:00
|
|
|
const struct View2D *v2d, int colorid, float step, int level_size, int totlevels);
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
|
|
|
|
|
void UI_view2d_draw_lines_y__values(const struct View2D *v2d);
|
|
|
|
|
void UI_view2d_draw_lines_x__values(const struct View2D *v2d);
|
|
|
|
|
void UI_view2d_draw_lines_x__discrete_values(const struct View2D *v2d);
|
|
|
|
|
void UI_view2d_draw_lines_x__discrete_time(const struct View2D *v2d, const struct Scene *scene);
|
|
|
|
|
void UI_view2d_draw_lines_x__discrete_frames_or_seconds(const struct View2D *v2d,
|
|
|
|
|
const struct Scene *scene,
|
|
|
|
|
bool display_seconds);
|
|
|
|
|
void UI_view2d_draw_lines_x__frames_or_seconds(const struct View2D *v2d,
|
|
|
|
|
const struct Scene *scene,
|
|
|
|
|
bool display_seconds);
|
|
|
|
|
|
|
|
|
|
float UI_view2d_grid_resolution_x__frames_or_seconds(const struct View2D *v2d,
|
|
|
|
|
const struct Scene *scene,
|
|
|
|
|
bool display_seconds);
|
|
|
|
|
float UI_view2d_grid_resolution_y__values(const struct View2D *v2d);
|
|
|
|
|
|
|
|
|
|
/* scale indicator text drawing */
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_draw_scale_y__values(const struct ARegion *region,
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
const struct View2D *v2d,
|
2019-05-03 15:09:28 +02:00
|
|
|
const struct rcti *rect,
|
|
|
|
|
int colorid);
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_draw_scale_y__block(const struct ARegion *region,
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
const struct View2D *v2d,
|
2019-05-03 15:09:28 +02:00
|
|
|
const struct rcti *rect,
|
|
|
|
|
int colorid);
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_draw_scale_x__discrete_frames_or_seconds(const struct ARegion *region,
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
const struct View2D *v2d,
|
|
|
|
|
const struct rcti *rect,
|
|
|
|
|
const struct Scene *scene,
|
2019-05-03 15:09:28 +02:00
|
|
|
bool display_seconds,
|
|
|
|
|
int colorid);
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_draw_scale_x__frames_or_seconds(const struct ARegion *region,
|
Refactor grid and scale indicator text drawing
This affects the timeline, dopesheet, graph editor, sequencer,
clip editor and nla editor.
Removed structs and enums: `V2D_ARG_DUMMY`, `eView2D_Units`,
`eView2D_Clamp`, `eView2D_Gridlines`, `View2DGrid`.
A main goal of this refactor is to get rid of the very generic
`View2DGrid` struct. The drawing code became very complex
because there were many different combinations of settings.
This refactor implements a different approach.
Instead of one very generic API, there are many slighly
different functions that do exactly, what we need in the
different editors. Only very little code is duplicated,
because the API functions compose some shared low level code.
This structure makes the code much easier to debug and change,
because every function has much fewer responsibilities.
Additionally, this refactor fixes some long standing bugs.
E.g. when `Show Seconds` is enabled, you zoom in and pan the view.
Or that the step size between displayed frame numbers was
always `>= 2`, no matter how close you zoom in.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4776
2019-05-02 12:00:12 +02:00
|
|
|
const struct View2D *v2d,
|
|
|
|
|
const struct rcti *rect,
|
|
|
|
|
const struct Scene *scene,
|
2019-05-03 15:09:28 +02:00
|
|
|
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
|
|
|
|
2008-11-28 04:01:35 +00:00
|
|
|
/* scrollbar drawing */
|
2020-06-22 21:44:18 +02:00
|
|
|
void UI_view2d_scrollers_calc(struct View2D *v2d,
|
|
|
|
|
const struct rcti *mask_custom,
|
|
|
|
|
struct View2DScrollers *r_scrollers);
|
|
|
|
|
void UI_view2d_scrollers_draw(struct View2D *v2d, const struct rcti *mask_custom);
|
2008-11-28 04:01:35 +00:00
|
|
|
|
2008-12-31 10:44:00 +00:00
|
|
|
/* list view tools */
|
2019-05-03 13:00:18 +02:00
|
|
|
void UI_view2d_listview_view_to_cell(float columnwidth,
|
2013-06-04 20:26:58 +00:00
|
|
|
float rowheight,
|
2012-09-15 11:48:20 +00:00
|
|
|
float startx,
|
|
|
|
|
float starty,
|
|
|
|
|
float viewx,
|
|
|
|
|
float viewy,
|
|
|
|
|
int *column,
|
|
|
|
|
int *row);
|
2008-12-31 10:44:00 +00:00
|
|
|
|
Port of part of the Interface code to 2.50.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
2008-11-11 18:31:32 +00:00
|
|
|
/* coordinate conversion */
|
2018-11-13 13:28:43 +11:00
|
|
|
float UI_view2d_region_to_view_x(const struct View2D *v2d, float x);
|
|
|
|
|
float UI_view2d_region_to_view_y(const struct View2D *v2d, float y);
|
|
|
|
|
void UI_view2d_region_to_view(
|
|
|
|
|
const struct View2D *v2d, float x, float y, float *r_view_x, float *r_view_y) ATTR_NONNULL();
|
|
|
|
|
void UI_view2d_region_to_view_rctf(const struct View2D *v2d,
|
|
|
|
|
const struct rctf *rect_src,
|
|
|
|
|
struct rctf *rect_dst) ATTR_NONNULL();
|
|
|
|
|
|
|
|
|
|
float UI_view2d_view_to_region_x(const struct View2D *v2d, float x);
|
|
|
|
|
float UI_view2d_view_to_region_y(const struct View2D *v2d, float y);
|
|
|
|
|
bool UI_view2d_view_to_region_clip(
|
|
|
|
|
const struct View2D *v2d, float x, float y, int *r_region_x, int *r_region_y) ATTR_NONNULL();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-04-21 16:47:16 +10:00
|
|
|
void UI_view2d_view_to_region(
|
2020-05-04 19:32:59 +10:00
|
|
|
const struct View2D *v2d, float x, float y, int *r_region_x, int *r_region_y) ATTR_NONNULL();
|
|
|
|
|
void UI_view2d_view_to_region_fl(const struct View2D *v2d,
|
|
|
|
|
float x,
|
|
|
|
|
float y,
|
|
|
|
|
float *r_region_x,
|
|
|
|
|
float *r_region_y) ATTR_NONNULL();
|
|
|
|
|
void UI_view2d_view_to_region_m4(const struct View2D *v2d, float matrix[4][4]) ATTR_NONNULL();
|
|
|
|
|
void UI_view2d_view_to_region_rcti(const struct View2D *v2d,
|
2014-04-21 16:47:16 +10:00
|
|
|
const struct rctf *rect_src,
|
|
|
|
|
struct rcti *rect_dst) ATTR_NONNULL();
|
2020-05-04 19:32:59 +10:00
|
|
|
bool UI_view2d_view_to_region_rcti_clip(const struct View2D *v2d,
|
2014-04-21 16:47:16 +10:00
|
|
|
const struct rctf *rect_src,
|
|
|
|
|
struct 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
|
|
|
|
2008-11-24 18:59:59 +00:00
|
|
|
/* utilities */
|
2008-12-02 09:43:23 +00:00
|
|
|
struct View2D *UI_view2d_fromcontext(const struct bContext *C);
|
2008-12-11 15:38:16 +00:00
|
|
|
struct View2D *UI_view2d_fromcontext_rwin(const struct bContext *C);
|
2008-12-23 11:02:39 +00:00
|
|
|
|
2019-12-04 16:00:03 +01:00
|
|
|
void UI_view2d_scroller_size_get(const struct View2D *v2d, float *r_x, float *r_y);
|
2021-01-15 10:48:22 -06:00
|
|
|
void UI_view2d_scale_get(const struct View2D *v2d, float *r_x, float *r_y);
|
2019-04-16 14:15:49 +02:00
|
|
|
float UI_view2d_scale_get_x(const struct View2D *v2d);
|
|
|
|
|
float UI_view2d_scale_get_y(const struct View2D *v2d);
|
2020-05-04 19:32:59 +10:00
|
|
|
void UI_view2d_scale_get_inverse(const struct View2D *v2d, float *r_x, float *r_y);
|
2008-11-24 18:59:59 +00:00
|
|
|
|
2020-05-04 19:32:59 +10:00
|
|
|
void UI_view2d_center_get(const struct View2D *v2d, float *r_x, float *r_y);
|
2014-04-21 18:46:52 +10:00
|
|
|
void UI_view2d_center_set(struct View2D *v2d, float x, float y);
|
2013-03-18 16:34:57 +00:00
|
|
|
|
2014-02-22 13:07:02 +11:00
|
|
|
void UI_view2d_offset(struct View2D *v2d, float xfac, float yfac);
|
|
|
|
|
|
2018-11-07 18:14:21 +11:00
|
|
|
char UI_view2d_mouse_in_scrollers_ex(
|
2020-03-06 16:56:42 +01:00
|
|
|
const struct ARegion *region, const struct View2D *v2d, int x, int y, int *r_scroll);
|
|
|
|
|
char UI_view2d_mouse_in_scrollers(const struct ARegion *region,
|
2019-03-21 14:19:45 +11:00
|
|
|
const struct View2D *v2d,
|
|
|
|
|
int x,
|
|
|
|
|
int y);
|
2020-03-06 16:56:42 +01:00
|
|
|
char UI_view2d_rect_in_scrollers_ex(const struct ARegion *region,
|
2019-04-23 16:43:50 +10:00
|
|
|
const struct View2D *v2d,
|
|
|
|
|
const struct rcti *rect,
|
|
|
|
|
int *r_scroll);
|
2020-03-06 16:56:42 +01:00
|
|
|
char UI_view2d_rect_in_scrollers(const struct ARegion *region,
|
2019-04-23 16:43:50 +10:00
|
|
|
const struct View2D *v2d,
|
|
|
|
|
const struct rcti *rect);
|
2008-12-23 11:02:39 +00:00
|
|
|
|
2009-06-01 16:22:53 +00:00
|
|
|
/* cached text drawing in v2d, to allow pixel-aligned draw as post process */
|
2020-03-16 11:53:08 +11:00
|
|
|
void UI_view2d_text_cache_add(struct View2D *v2d,
|
|
|
|
|
float x,
|
|
|
|
|
float y,
|
|
|
|
|
const char *str,
|
|
|
|
|
size_t str_len,
|
|
|
|
|
const unsigned char col[4]);
|
2014-04-21 18:46:52 +10:00
|
|
|
void UI_view2d_text_cache_add_rectf(struct View2D *v2d,
|
|
|
|
|
const struct rctf *rect_view,
|
|
|
|
|
const char *str,
|
|
|
|
|
size_t str_len,
|
2020-03-16 11:53:08 +11:00
|
|
|
const unsigned char col[4]);
|
2020-03-06 16:56:42 +01:00
|
|
|
void UI_view2d_text_cache_draw(struct ARegion *region);
|
2008-12-23 11:02:39 +00:00
|
|
|
|
2008-11-30 06:15:33 +00:00
|
|
|
/* operators */
|
2014-03-16 22:11:14 +11:00
|
|
|
void ED_operatortypes_view2d(void);
|
|
|
|
|
void ED_keymap_view2d(struct wmKeyConfig *keyconf);
|
2008-11-24 18:59:59 +00:00
|
|
|
|
2012-08-12 01:07:31 +00:00
|
|
|
void UI_view2d_smooth_view(struct bContext *C,
|
2020-03-06 16:56:42 +01:00
|
|
|
struct ARegion *region,
|
2013-09-16 04:04:44 +00:00
|
|
|
const struct rctf *cur,
|
|
|
|
|
const int smooth_viewtx);
|
2019-05-07 15:09:14 +02:00
|
|
|
|
2014-10-28 18:51:28 +01:00
|
|
|
#define UI_MARKER_MARGIN_Y (42 * UI_DPI_FAC)
|
2019-05-28 16:17:15 +10:00
|
|
|
#define UI_TIME_SCRUB_MARGIN_Y (23 * UI_DPI_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
|
|
|
|
2019-05-31 21:45:28 +10:00
|
|
|
/* Gizmo Types */
|
|
|
|
|
|
|
|
|
|
/* view2d_gizmo_navigate.c */
|
|
|
|
|
/* Caller passes in own idname. */
|
|
|
|
|
void VIEW2D_GGT_navigate_impl(struct wmGizmoGroupType *gzgt, const char *idname);
|
|
|
|
|
|
2021-06-16 18:17:07 +01:00
|
|
|
/* Edge pan */
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Custom-data for view panning operators.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct View2DEdgePanData {
|
|
|
|
|
/** Screen where view pan was initiated. */
|
|
|
|
|
struct bScreen *screen;
|
|
|
|
|
/** Area where view pan was initiated. */
|
|
|
|
|
struct ScrArea *area;
|
|
|
|
|
/** Region where view pan was initiated. */
|
|
|
|
|
struct ARegion *region;
|
|
|
|
|
/** View2d we're operating in. */
|
|
|
|
|
struct View2D *v2d;
|
|
|
|
|
|
|
|
|
|
/** 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;
|
|
|
|
|
|
|
|
|
|
/** 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;
|
|
|
|
|
} View2DEdgePanData;
|
|
|
|
|
|
|
|
|
|
bool UI_view2d_edge_pan_poll(struct bContext *C);
|
|
|
|
|
|
|
|
|
|
void UI_view2d_edge_pan_init(struct bContext *C,
|
|
|
|
|
struct View2DEdgePanData *vpd,
|
|
|
|
|
float inside_pad,
|
|
|
|
|
float outside_pad,
|
|
|
|
|
float speed_ramp,
|
|
|
|
|
float max_speed,
|
|
|
|
|
float delay);
|
|
|
|
|
|
|
|
|
|
void UI_view2d_edge_pan_reset(struct View2DEdgePanData *vpd);
|
|
|
|
|
|
|
|
|
|
/* Apply transform to view (i.e. adjust 'cur' rect). */
|
|
|
|
|
void UI_view2d_edge_pan_apply(struct bContext *C, struct View2DEdgePanData *vpd, int x, int y);
|
|
|
|
|
|
|
|
|
|
/* Apply transform to view using mouse events. */
|
|
|
|
|
void UI_view2d_edge_pan_apply_event(struct bContext *C,
|
|
|
|
|
struct View2DEdgePanData *vpd,
|
|
|
|
|
const struct wmEvent *event);
|
|
|
|
|
|
|
|
|
|
void UI_view2d_edge_pan_operator_properties(struct wmOperatorType *ot);
|
|
|
|
|
|
|
|
|
|
void UI_view2d_edge_pan_operator_properties_ex(struct wmOperatorType *ot,
|
|
|
|
|
float inside_pad,
|
|
|
|
|
float outside_pad,
|
|
|
|
|
float speed_ramp,
|
|
|
|
|
float max_speed,
|
|
|
|
|
float delay);
|
|
|
|
|
|
|
|
|
|
/* Initialize panning data with operator settings. */
|
|
|
|
|
void UI_view2d_edge_pan_operator_init(struct bContext *C,
|
|
|
|
|
struct View2DEdgePanData *vpd,
|
|
|
|
|
struct wmOperator *op);
|
|
|
|
|
|
2020-03-02 15:09:10 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|