2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2008-01-19 17:54:05 +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
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2008-01-19 17:54:05 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup wm
|
2014-01-19 23:14:24 +11:00
|
|
|
*
|
|
|
|
* Gestures (cursor motions) creating, evaluating and drawing, shared between operators.
|
2011-02-25 14:04:21 +00:00
|
|
|
*/
|
|
|
|
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
#include "DNA_vec_types.h"
|
2.5: WM Compositing
* Triple Buffer is now more complete:
- Proper handling of window resize, duplicate, etc.
- It now uses 3x3 textures (or less) if the power of two sizes
do not match well. That still has a worst case wast of 23.4%,
but better than 300%.
- It can also use the ARB/NV/EXT_texture_rectangle extension
now, which may be supported on hardware that does not support
ARB_texture_non_power_of_two.
- Gesture, menu and brushe redraws now require no redraws at all
from the area regions. So even on a high poly scene just moving
the paint cursor or opening a menu should be fast.
* Testing can be done by setting the "Window Draw Method" in the
User Preferences in the outliner. "Overlap" is still default,
since "Triple Buffer" has not been tested on computers other than
mine, would like to avoid crashing Blender on startup in case
there is a common bug, but it's ready for testing now.
- For reference "Full" draws the full window each time.
- "Triple Buffer" should work for both swap copy and swap exchange
systems, the latter still need the -E command line option for
"Overlap".
- Resizing and going fullscreen still gives flicker here but no
more than "Full" drawing.
* Partial Redraw was added. ED_region_tag_redraw_partial takes a
rect in window coordinates to define a subarea of the region.
On region draw it will then set glScissor to a smaller area, and
ar->drawrct will always be set to either the partial or full
window rect. The latter can then be used for clipping in the 3D
view or clipping interface drawing. Neither is implemented yet.
2009-01-23 03:52:52 +00:00
|
|
|
#include "DNA_userdef_types.h"
|
2008-01-19 17:54:05 +00:00
|
|
|
#include "DNA_windowmanager_types.h"
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
2016-10-26 20:11:09 +11:00
|
|
|
#include "BLI_bitmap_draw_2d.h"
|
2008-01-19 17:54:05 +00:00
|
|
|
#include "BLI_blenlib.h"
|
2010-01-26 11:25:39 +00:00
|
|
|
#include "BLI_math.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BLI_utildefines.h"
|
2018-02-18 21:27:33 +11:00
|
|
|
#include "BLI_lasso_2d.h"
|
2008-01-19 17:54:05 +00:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
#include "BKE_context.h"
|
2011-01-07 19:18:31 +00:00
|
|
|
|
2008-01-19 17:54:05 +00:00
|
|
|
#include "WM_api.h"
|
|
|
|
#include "WM_types.h"
|
|
|
|
|
2009-01-02 14:11:18 +00:00
|
|
|
#include "wm.h"
|
2010-03-22 11:59:36 +00:00
|
|
|
#include "wm_draw.h"
|
2008-01-19 21:54:33 +00:00
|
|
|
|
2017-02-24 15:33:09 -05:00
|
|
|
#include "GPU_immediate.h"
|
2017-04-05 18:30:14 +10:00
|
|
|
#include "GPU_immediate_util.h"
|
2018-12-11 23:05:36 +01:00
|
|
|
#include "GPU_state.h"
|
2008-12-27 16:09:56 +00:00
|
|
|
|
2008-01-19 17:54:05 +00:00
|
|
|
#include "BIF_glutil.h"
|
|
|
|
|
2008-11-24 14:16:04 +00:00
|
|
|
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
/* context checked on having screen, window and area */
|
2013-03-13 09:03:46 +00:00
|
|
|
wmGesture *WM_gesture_new(bContext *C, const wmEvent *event, int type)
|
2008-01-19 21:54:33 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
wmGesture *gesture = MEM_callocN(sizeof(wmGesture), "new gesture");
|
|
|
|
wmWindow *window = CTX_wm_window(C);
|
|
|
|
ARegion *ar = CTX_wm_region(C);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
BLI_addtail(&window->gesture, gesture);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-27 01:24:16 +00:00
|
|
|
gesture->type = type;
|
|
|
|
gesture->event_type = event->type;
|
2018-02-16 22:41:46 +01:00
|
|
|
gesture->winrct = ar->winrct;
|
2017-10-02 01:34:51 +11:00
|
|
|
gesture->userdata_free = true; /* Free if userdata is set. */
|
2017-10-16 21:58:51 +11:00
|
|
|
gesture->modal_state = GESTURE_MODAL_NOP;
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2014-07-20 01:30:29 +10:00
|
|
|
if (ELEM(type, WM_GESTURE_RECT, WM_GESTURE_CROSS_RECT, WM_GESTURE_TWEAK,
|
2012-03-27 01:24:16 +00:00
|
|
|
WM_GESTURE_CIRCLE, WM_GESTURE_STRAIGHTLINE))
|
2012-02-19 06:00:20 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
rcti *rect = MEM_callocN(sizeof(rcti), "gesture rect new");
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-27 01:24:16 +00:00
|
|
|
gesture->customdata = rect;
|
2018-02-16 22:41:46 +01:00
|
|
|
rect->xmin = event->x - gesture->winrct.xmin;
|
|
|
|
rect->ymin = event->y - gesture->winrct.ymin;
|
2012-03-27 01:24:16 +00:00
|
|
|
if (type == WM_GESTURE_CIRCLE) {
|
2017-10-16 15:32:09 +11:00
|
|
|
/* caller is responsible for initializing 'xmax' to radius. */
|
2012-03-24 06:24:53 +00:00
|
|
|
}
|
|
|
|
else {
|
2018-02-16 22:41:46 +01:00
|
|
|
rect->xmax = event->x - gesture->winrct.xmin;
|
|
|
|
rect->ymax = event->y - gesture->winrct.ymin;
|
2008-12-21 16:24:19 +00:00
|
|
|
}
|
2008-01-19 21:54:33 +00:00
|
|
|
}
|
2009-02-07 14:03:34 +00:00
|
|
|
else if (ELEM(type, WM_GESTURE_LINES, WM_GESTURE_LASSO)) {
|
2009-01-02 14:11:18 +00:00
|
|
|
short *lasso;
|
2017-10-16 13:18:50 +11:00
|
|
|
gesture->points_alloc = 1024;
|
|
|
|
gesture->customdata = lasso = MEM_mallocN(sizeof(short[2]) * gesture->points_alloc, "lasso points");
|
2018-02-16 22:41:46 +01:00
|
|
|
lasso[0] = event->x - gesture->winrct.xmin;
|
|
|
|
lasso[1] = event->y - gesture->winrct.ymin;
|
2012-03-27 01:24:16 +00:00
|
|
|
gesture->points = 1;
|
2009-01-02 14:11:18 +00:00
|
|
|
}
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
return gesture;
|
2008-01-19 21:54:33 +00:00
|
|
|
}
|
|
|
|
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
void WM_gesture_end(bContext *C, wmGesture *gesture)
|
2008-01-19 17:54:05 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
wmWindow *win = CTX_wm_window(C);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-27 01:24:16 +00:00
|
|
|
if (win->tweak == gesture)
|
|
|
|
win->tweak = NULL;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
BLI_remlink(&win->gesture, gesture);
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
MEM_freeN(gesture->customdata);
|
2017-10-02 01:34:51 +11:00
|
|
|
if (gesture->userdata && gesture->userdata_free) {
|
2012-12-22 01:08:42 +00:00
|
|
|
MEM_freeN(gesture->userdata);
|
|
|
|
}
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
MEM_freeN(gesture);
|
2008-01-19 17:54:05 +00:00
|
|
|
}
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
void WM_gestures_remove(bContext *C)
|
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
wmWindow *win = CTX_wm_window(C);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-24 06:24:53 +00:00
|
|
|
while (win->gesture.first)
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
WM_gesture_end(C, win->gesture.first);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-11-24 10:45:36 +00:00
|
|
|
/* tweak and line gestures */
|
2010-10-16 02:40:31 +00:00
|
|
|
int wm_gesture_evaluate(wmGesture *gesture)
|
2008-11-24 10:45:36 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
if (gesture->type == WM_GESTURE_TWEAK) {
|
|
|
|
rcti *rect = gesture->customdata;
|
2012-09-15 11:48:20 +00:00
|
|
|
int dx = BLI_rcti_size_x(rect);
|
|
|
|
int dy = BLI_rcti_size_y(rect);
|
2018-11-21 19:25:13 +01:00
|
|
|
float tweak_threshold = U.tweak_threshold * U.dpi_fac;
|
|
|
|
if (abs(dx) + abs(dy) > tweak_threshold) {
|
2017-09-27 11:13:03 +10:00
|
|
|
int theta = round_fl_to_int(4.0f * atan2f((float)dy, (float)dx) / (float)M_PI);
|
2012-03-27 01:24:16 +00:00
|
|
|
int val = EVT_GESTURE_W;
|
|
|
|
|
|
|
|
if (theta == 0) val = EVT_GESTURE_E;
|
|
|
|
else if (theta == 1) val = EVT_GESTURE_NE;
|
|
|
|
else if (theta == 2) val = EVT_GESTURE_N;
|
|
|
|
else if (theta == 3) val = EVT_GESTURE_NW;
|
|
|
|
else if (theta == -1) val = EVT_GESTURE_SE;
|
|
|
|
else if (theta == -2) val = EVT_GESTURE_S;
|
|
|
|
else if (theta == -3) val = EVT_GESTURE_SW;
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2.5: work on bringing back SpaceTime options
- RMB select, also with SHIFT
- RMB tweak for translate
- SHIFT+D dupli
- BKEY border select/deselect
- AKEY (de)select all
- XKEY delete
- GKEY grab
Added some XXX comments for future todos, especially for when other
spaces come back with time markers.
Also added ED_util for putting in all to-be-cleaned cruft
Context conflict: input methods for Markers can conflict with other
spacetypes. It was solved in pre-2.5 with manually tweaking it all over,
but I would prefer one keymap for all marker stuff. Needs some thinking...
could be solved with a boundbox check for bottom part of 2d window.
Tweak issue: both tweak styles are possible:
- Hold mouse button, move, operator ends on mouse release
- Hold mouse button, move, operator ends on mouse click
Problem is that modally handled operators use fixed keymaps... like ESC,
SPACE, ENTER, or press/release mousebutton for 'assign'. There's a lot
to say for making this all consistant, or become part of 1 general keymap?
Should also be possibe to define 'tweak' defaults for Tablet different
than for mouse...
2008-11-29 15:10:31 +00:00
|
|
|
#if 0
|
2008-11-24 10:45:36 +00:00
|
|
|
/* debug */
|
2012-03-27 01:24:16 +00:00
|
|
|
if (val == 1) printf("tweak north\n");
|
|
|
|
if (val == 2) printf("tweak north-east\n");
|
|
|
|
if (val == 3) printf("tweak east\n");
|
|
|
|
if (val == 4) printf("tweak south-east\n");
|
|
|
|
if (val == 5) printf("tweak south\n");
|
|
|
|
if (val == 6) printf("tweak south-west\n");
|
|
|
|
if (val == 7) printf("tweak west\n");
|
|
|
|
if (val == 8) printf("tweak north-west\n");
|
2012-05-19 13:55:54 +00:00
|
|
|
#endif
|
2008-11-24 10:45:36 +00:00
|
|
|
return val;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2008-01-19 21:54:33 +00:00
|
|
|
|
|
|
|
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
/* ******************* gesture draw ******************* */
|
2008-01-19 17:54:05 +00:00
|
|
|
|
2017-02-24 15:33:09 -05:00
|
|
|
static void wm_gesture_draw_line(wmGesture *gt)
|
|
|
|
{
|
|
|
|
rcti *rect = (rcti *)gt->customdata;
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
uint shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-07-13 16:44:02 +02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-26 20:51:17 +02:00
|
|
|
float viewport_size[4];
|
|
|
|
glGetFloatv(GL_VIEWPORT, viewport_size);
|
|
|
|
immUniform2f("viewport_size", viewport_size[2], viewport_size[3]);
|
|
|
|
|
2018-07-01 08:42:16 +02:00
|
|
|
immUniform1i("colors_len", 2); /* "advanced" mode */
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immUniformArray4fv("colors", (float *)(float[][4]){{0.4f, 0.4f, 0.4f, 1.0f}, {1.0f, 1.0f, 1.0f, 1.0f}}, 2);
|
2017-02-24 15:33:09 -05:00
|
|
|
immUniform1f("dash_width", 8.0f);
|
|
|
|
|
|
|
|
float xmin = (float)rect->xmin;
|
|
|
|
float ymin = (float)rect->ymin;
|
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
immBegin(GPU_PRIM_LINES, 2);
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immVertex2f(shdr_pos, xmin, ymin);
|
|
|
|
immVertex2f(shdr_pos, (float)rect->xmax, (float)rect->ymax);
|
2017-02-24 15:33:09 -05:00
|
|
|
immEnd();
|
|
|
|
|
|
|
|
immUnbindProgram();
|
|
|
|
}
|
|
|
|
|
2010-10-16 02:40:31 +00:00
|
|
|
static void wm_gesture_draw_rect(wmGesture *gt)
|
2008-01-19 17:54:05 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
rcti *rect = (rcti *)gt->customdata;
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
uint shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_I32, 2, GPU_FETCH_INT_TO_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2010-01-06 04:52:13 +00:00
|
|
|
glEnable(GL_BLEND);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-07 15:03:24 -04:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
|
2017-04-16 12:25:42 -04:00
|
|
|
immUniformColor4f(1.0f, 1.0f, 1.0f, 0.05f);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immRecti(shdr_pos, rect->xmin, rect->ymin, rect->xmax, rect->ymax);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immUnbindProgram();
|
|
|
|
|
2010-01-06 04:52:13 +00:00
|
|
|
glDisable(GL_BLEND);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-07-13 16:44:02 +02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-26 20:51:17 +02:00
|
|
|
float viewport_size[4];
|
|
|
|
glGetFloatv(GL_VIEWPORT, viewport_size);
|
|
|
|
immUniform2f("viewport_size", viewport_size[2], viewport_size[3]);
|
|
|
|
|
2018-07-01 08:42:16 +02:00
|
|
|
immUniform1i("colors_len", 2); /* "advanced" mode */
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immUniformArray4fv("colors", (float *)(float[][4]){{0.4f, 0.4f, 0.4f, 1.0f}, {1.0f, 1.0f, 1.0f, 1.0f}}, 2);
|
2017-02-24 15:33:09 -05:00
|
|
|
immUniform1f("dash_width", 8.0f);
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
|
2017-09-26 15:21:01 +10:00
|
|
|
imm_draw_box_wire_2d(shdr_pos, (float)rect->xmin, (float)rect->ymin, (float)rect->xmax, (float)rect->ymax);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immUnbindProgram();
|
|
|
|
|
|
|
|
// wm_gesture_draw_line(gt); // draws a diagonal line in the lined box to test wm_gesture_draw_line
|
2008-01-19 17:54:05 +00:00
|
|
|
}
|
|
|
|
|
2010-10-16 02:40:31 +00:00
|
|
|
static void wm_gesture_draw_circle(wmGesture *gt)
|
2008-12-21 16:24:19 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
rcti *rect = (rcti *)gt->customdata;
|
2008-12-21 16:24:19 +00:00
|
|
|
|
2010-01-06 04:52:13 +00:00
|
|
|
glEnable(GL_BLEND);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
const uint shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
|
|
|
|
|
2017-04-16 13:44:34 -04:00
|
|
|
immUniformColor4f(1.0f, 1.0f, 1.0f, 0.05f);
|
2017-09-14 00:39:28 +10:00
|
|
|
imm_draw_circle_fill_2d(shdr_pos, (float)rect->xmin, (float)rect->ymin, (float)rect->xmax, 40);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immUnbindProgram();
|
|
|
|
|
2010-01-06 04:52:13 +00:00
|
|
|
glDisable(GL_BLEND);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-07-13 16:44:02 +02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-26 20:51:17 +02:00
|
|
|
float viewport_size[4];
|
|
|
|
glGetFloatv(GL_VIEWPORT, viewport_size);
|
|
|
|
immUniform2f("viewport_size", viewport_size[2], viewport_size[3]);
|
|
|
|
|
2018-07-01 08:42:16 +02:00
|
|
|
immUniform1i("colors_len", 2); /* "advanced" mode */
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immUniformArray4fv("colors", (float *)(float[][4]){{0.4f, 0.4f, 0.4f, 1.0f}, {1.0f, 1.0f, 1.0f, 1.0f}}, 2);
|
2017-02-24 15:33:09 -05:00
|
|
|
immUniform1f("dash_width", 4.0f);
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
|
2017-09-14 00:39:28 +10:00
|
|
|
imm_draw_circle_wire_2d(shdr_pos, (float)rect->xmin, (float)rect->ymin, (float)rect->xmax, 40);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immUnbindProgram();
|
2008-12-21 16:24:19 +00:00
|
|
|
}
|
|
|
|
|
2013-10-04 15:02:05 +00:00
|
|
|
struct LassoFillData {
|
2016-06-09 05:02:52 +10:00
|
|
|
unsigned char *px;
|
2013-10-04 15:02:05 +00:00
|
|
|
int width;
|
|
|
|
};
|
|
|
|
|
2016-01-08 23:29:42 +11:00
|
|
|
static void draw_filled_lasso_px_cb(int x, int x_end, int y, void *user_data)
|
2013-10-04 15:02:05 +00:00
|
|
|
{
|
|
|
|
struct LassoFillData *data = user_data;
|
2016-06-09 05:02:52 +10:00
|
|
|
unsigned char *col = &(data->px[(y * data->width) + x]);
|
|
|
|
memset(col, 0x10, x_end - x);
|
2013-10-04 15:02:05 +00:00
|
|
|
}
|
|
|
|
|
2018-02-16 22:41:46 +01:00
|
|
|
static void draw_filled_lasso(wmGesture *gt)
|
2009-01-02 14:11:18 +00:00
|
|
|
{
|
2014-04-27 00:21:43 +10:00
|
|
|
const short *lasso = (short *)gt->customdata;
|
2013-10-04 15:02:05 +00:00
|
|
|
const int tot = gt->points;
|
|
|
|
int (*moves)[2] = MEM_mallocN(sizeof(*moves) * (tot + 1), __func__);
|
2009-01-02 14:11:18 +00:00
|
|
|
int i;
|
2013-10-04 15:02:05 +00:00
|
|
|
rcti rect;
|
2017-02-24 01:17:48 +01:00
|
|
|
float red[4] = {1.0f, 0.0f, 0.0f, 0.0f};
|
2013-10-04 15:02:05 +00:00
|
|
|
|
|
|
|
for (i = 0; i < tot; i++, lasso += 2) {
|
|
|
|
moves[i][0] = lasso[0];
|
|
|
|
moves[i][1] = lasso[1];
|
2010-01-07 01:27:10 +00:00
|
|
|
}
|
2013-10-04 15:02:05 +00:00
|
|
|
|
|
|
|
BLI_lasso_boundbox(&rect, (const int (*)[2])moves, tot);
|
|
|
|
|
2018-02-16 22:41:46 +01:00
|
|
|
BLI_rcti_translate(&rect, gt->winrct.xmin, gt->winrct.ymin);
|
|
|
|
BLI_rcti_isect(>->winrct, &rect, &rect);
|
|
|
|
BLI_rcti_translate(&rect, -gt->winrct.xmin, -gt->winrct.ymin);
|
2013-10-04 15:02:05 +00:00
|
|
|
|
|
|
|
/* highly unlikely this will fail, but could crash if (tot == 0) */
|
|
|
|
if (BLI_rcti_is_empty(&rect) == false) {
|
|
|
|
const int w = BLI_rcti_size_x(&rect);
|
|
|
|
const int h = BLI_rcti_size_y(&rect);
|
2016-06-09 05:02:52 +10:00
|
|
|
unsigned char *pixel_buf = MEM_callocN(sizeof(*pixel_buf) * w * h, __func__);
|
2013-10-04 15:02:05 +00:00
|
|
|
struct LassoFillData lasso_fill_data = {pixel_buf, w};
|
|
|
|
|
2016-10-26 20:14:48 +11:00
|
|
|
BLI_bitmap_draw_2d_poly_v2i_n(
|
2013-10-04 15:02:05 +00:00
|
|
|
rect.xmin, rect.ymin, rect.xmax, rect.ymax,
|
|
|
|
(const int (*)[2])moves, tot,
|
|
|
|
draw_filled_lasso_px_cb, &lasso_fill_data);
|
|
|
|
|
2017-02-24 01:17:48 +01:00
|
|
|
/* Additive Blending */
|
|
|
|
glEnable(GL_BLEND);
|
|
|
|
glBlendFunc(GL_ONE, GL_ONE);
|
|
|
|
|
2017-04-04 18:38:26 +02:00
|
|
|
GLint unpack_alignment;
|
|
|
|
glGetIntegerv(GL_UNPACK_ALIGNMENT, &unpack_alignment);
|
|
|
|
|
2016-06-09 05:02:52 +10:00
|
|
|
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
|
|
|
|
|
2017-04-11 16:30:00 +02:00
|
|
|
IMMDrawPixelsTexState state = immDrawPixelsTexSetup(GPU_SHADER_2D_IMAGE_SHUFFLE_COLOR);
|
|
|
|
GPU_shader_bind(state.shader);
|
2019-01-16 04:41:27 +01:00
|
|
|
GPU_shader_uniform_vector(state.shader, GPU_shader_get_uniform_ensure(state.shader, "shuffle"), 4, 1, red);
|
2016-06-09 05:02:52 +10:00
|
|
|
|
2017-04-11 16:30:00 +02:00
|
|
|
immDrawPixelsTex(&state, rect.xmin, rect.ymin, w, h, GL_RED, GL_UNSIGNED_BYTE, GL_NEAREST, pixel_buf, 1.0f, 1.0f, NULL);
|
2013-10-04 15:02:05 +00:00
|
|
|
|
2017-02-24 01:17:48 +01:00
|
|
|
GPU_shader_unbind();
|
2013-10-04 15:02:05 +00:00
|
|
|
|
2017-04-04 18:38:26 +02:00
|
|
|
glPixelStorei(GL_UNPACK_ALIGNMENT, unpack_alignment);
|
2016-06-08 04:03:25 +10:00
|
|
|
|
2013-10-04 15:02:05 +00:00
|
|
|
MEM_freeN(pixel_buf);
|
2017-02-24 01:17:48 +01:00
|
|
|
|
|
|
|
glDisable(GL_BLEND);
|
2018-04-25 13:07:22 +02:00
|
|
|
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
|
2010-01-15 17:19:01 +00:00
|
|
|
}
|
2013-10-04 15:02:05 +00:00
|
|
|
|
|
|
|
MEM_freeN(moves);
|
2010-01-07 01:27:10 +00:00
|
|
|
}
|
|
|
|
|
2013-10-04 15:02:05 +00:00
|
|
|
|
2018-02-16 22:41:46 +01:00
|
|
|
static void wm_gesture_draw_lasso(wmGesture *gt, bool filled)
|
2010-01-07 01:27:10 +00:00
|
|
|
{
|
2014-04-27 00:21:43 +10:00
|
|
|
const short *lasso = (short *)gt->customdata;
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
int i;
|
2010-01-06 06:51:04 +00:00
|
|
|
|
2013-10-29 00:05:03 +00:00
|
|
|
if (filled) {
|
2018-02-16 22:41:46 +01:00
|
|
|
draw_filled_lasso(gt);
|
2013-10-29 00:05:03 +00:00
|
|
|
}
|
|
|
|
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
const int numverts = gt->points;
|
2017-03-15 14:01:30 +01:00
|
|
|
|
2017-04-26 12:04:35 +02:00
|
|
|
/* Nothing to draw, do early output. */
|
2017-04-03 21:58:53 +10:00
|
|
|
if (numverts < 2) {
|
2017-03-15 14:01:30 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
const uint shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-07-13 16:44:02 +02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-26 20:51:17 +02:00
|
|
|
float viewport_size[4];
|
|
|
|
glGetFloatv(GL_VIEWPORT, viewport_size);
|
|
|
|
immUniform2f("viewport_size", viewport_size[2], viewport_size[3]);
|
|
|
|
|
2018-07-01 08:42:16 +02:00
|
|
|
immUniform1i("colors_len", 2); /* "advanced" mode */
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immUniformArray4fv("colors", (float *)(float[][4]){{0.4f, 0.4f, 0.4f, 1.0f}, {1.0f, 1.0f, 1.0f, 1.0f}}, 2);
|
2017-02-24 15:33:09 -05:00
|
|
|
immUniform1f("dash_width", 2.0f);
|
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
immBegin((gt->type == WM_GESTURE_LASSO) ? GPU_PRIM_LINE_LOOP : GPU_PRIM_LINE_STRIP, numverts);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
for (i = 0; i < gt->points; i++, lasso += 2) {
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immVertex2f(shdr_pos, (float)lasso[0], (float)lasso[1]);
|
2017-02-24 15:33:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
immEnd();
|
2017-03-15 14:01:30 +01:00
|
|
|
|
2017-02-24 15:33:09 -05:00
|
|
|
immUnbindProgram();
|
2009-01-02 14:11:18 +00:00
|
|
|
}
|
2008-12-21 16:24:19 +00:00
|
|
|
|
2008-11-24 10:45:36 +00:00
|
|
|
static void wm_gesture_draw_cross(wmWindow *win, wmGesture *gt)
|
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
rcti *rect = (rcti *)gt->customdata;
|
2013-12-11 12:42:04 +11:00
|
|
|
const int winsize_x = WM_window_pixels_x(win);
|
|
|
|
const int winsize_y = WM_window_pixels_y(win);
|
2013-02-10 18:03:01 +00:00
|
|
|
|
2017-02-24 15:33:09 -05:00
|
|
|
float x1, x2, y1, y2;
|
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
const uint shdr_pos = GPU_vertformat_attr_add(immVertexFormat(), "pos", GPU_COMP_F32, 2, GPU_FETCH_FLOAT);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-07-13 16:44:02 +02:00
|
|
|
immBindBuiltinProgram(GPU_SHADER_2D_LINE_DASHED_UNIFORM_COLOR);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
2017-04-26 20:51:17 +02:00
|
|
|
float viewport_size[4];
|
|
|
|
glGetFloatv(GL_VIEWPORT, viewport_size);
|
|
|
|
immUniform2f("viewport_size", viewport_size[2], viewport_size[3]);
|
|
|
|
|
2018-07-01 08:42:16 +02:00
|
|
|
immUniform1i("colors_len", 2); /* "advanced" mode */
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immUniformArray4fv("colors", (float *)(float[][4]){{0.4f, 0.4f, 0.4f, 1.0f}, {1.0f, 1.0f, 1.0f, 1.0f}}, 2);
|
2017-02-24 15:33:09 -05:00
|
|
|
immUniform1f("dash_width", 8.0f);
|
|
|
|
|
2018-07-18 00:12:21 +02:00
|
|
|
immBegin(GPU_PRIM_LINES, 4);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
x1 = (float)(rect->xmin - winsize_x);
|
|
|
|
y1 = (float)rect->ymin;
|
|
|
|
x2 = (float)(rect->xmin + winsize_x);
|
|
|
|
y2 = y1;
|
|
|
|
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immVertex2f(shdr_pos, x1, y1);
|
|
|
|
immVertex2f(shdr_pos, x2, y2);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
x1 = (float)rect->xmin;
|
|
|
|
y1 = (float)(rect->ymin - winsize_y);
|
|
|
|
x2 = x1;
|
|
|
|
y2 = (float)(rect->ymin + winsize_y);
|
|
|
|
|
Reworked version of dashed line shader.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
2017-05-01 16:21:53 +02:00
|
|
|
immVertex2f(shdr_pos, x1, y1);
|
|
|
|
immVertex2f(shdr_pos, x2, y2);
|
2017-02-24 15:33:09 -05:00
|
|
|
|
|
|
|
immEnd();
|
|
|
|
|
|
|
|
immUnbindProgram();
|
2008-01-19 21:54:33 +00:00
|
|
|
}
|
|
|
|
|
2009-07-19 12:15:20 +00:00
|
|
|
/* called in wm_draw.c */
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
void wm_gesture_draw(wmWindow *win)
|
2008-01-19 21:54:33 +00:00
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
wmGesture *gt = (wmGesture *)win->gesture.first;
|
2017-02-28 15:27:50 -05:00
|
|
|
|
2018-12-11 23:05:36 +01:00
|
|
|
GPU_line_width(1.0f);
|
2012-03-27 01:24:16 +00:00
|
|
|
for (; gt; gt = gt->next) {
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
/* all in subwindow space */
|
2018-02-16 22:41:46 +01:00
|
|
|
wmViewport(>->winrct);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-27 01:24:16 +00:00
|
|
|
if (gt->type == WM_GESTURE_RECT)
|
2010-10-16 02:40:31 +00:00
|
|
|
wm_gesture_draw_rect(gt);
|
2012-05-27 19:40:36 +00:00
|
|
|
// else if (gt->type == WM_GESTURE_TWEAK)
|
2010-12-23 10:34:37 +00:00
|
|
|
// wm_gesture_draw_line(gt);
|
2012-03-27 01:24:16 +00:00
|
|
|
else if (gt->type == WM_GESTURE_CIRCLE)
|
2010-10-16 02:40:31 +00:00
|
|
|
wm_gesture_draw_circle(gt);
|
2012-03-27 01:24:16 +00:00
|
|
|
else if (gt->type == WM_GESTURE_CROSS_RECT) {
|
2017-10-16 13:01:09 +11:00
|
|
|
if (gt->is_active) {
|
2010-10-16 02:40:31 +00:00
|
|
|
wm_gesture_draw_rect(gt);
|
2017-10-16 13:01:09 +11:00
|
|
|
}
|
|
|
|
else {
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
wm_gesture_draw_cross(win, gt);
|
2017-10-16 13:01:09 +11:00
|
|
|
}
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
}
|
2012-03-27 01:24:16 +00:00
|
|
|
else if (gt->type == WM_GESTURE_LINES)
|
2018-02-16 22:41:46 +01:00
|
|
|
wm_gesture_draw_lasso(gt, false);
|
2012-03-27 01:24:16 +00:00
|
|
|
else if (gt->type == WM_GESTURE_LASSO)
|
2018-02-16 22:41:46 +01:00
|
|
|
wm_gesture_draw_lasso(gt, true);
|
2012-03-27 01:24:16 +00:00
|
|
|
else if (gt->type == WM_GESTURE_STRAIGHTLINE)
|
2010-10-16 02:40:31 +00:00
|
|
|
wm_gesture_draw_line(gt);
|
2008-01-19 17:54:05 +00:00
|
|
|
}
|
|
|
|
}
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
|
2008-12-27 16:09:56 +00:00
|
|
|
void wm_gesture_tag_redraw(bContext *C)
|
|
|
|
{
|
2012-03-27 01:24:16 +00:00
|
|
|
bScreen *screen = CTX_wm_screen(C);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2012-03-24 06:24:53 +00:00
|
|
|
if (screen)
|
2014-04-01 11:34:00 +11:00
|
|
|
screen->do_draw_gesture = true;
|
2008-12-27 16:09:56 +00:00
|
|
|
}
|