2008-01-19 17:54:05 +00:00
|
|
|
/**
|
|
|
|
* $Id:
|
|
|
|
*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2008-11-24 14:16:04 +00:00
|
|
|
#define _USE_MATH_DEFINES
|
2008-11-24 10:45:36 +00:00
|
|
|
#include <math.h>
|
|
|
|
|
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"
|
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
#include "BKE_context.h"
|
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 "BKE_utildefines.h"
|
2008-01-19 21:54:33 +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"
|
2008-01-19 21:54:33 +00:00
|
|
|
#include "wm_event_system.h"
|
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 "wm_subwindow.h"
|
2008-01-19 21:54:33 +00:00
|
|
|
|
2008-12-27 16:09:56 +00:00
|
|
|
#include "ED_screen.h"
|
|
|
|
|
2008-01-19 17:54:05 +00:00
|
|
|
#include "BIF_gl.h"
|
|
|
|
#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 */
|
|
|
|
wmGesture *WM_gesture_new(bContext *C, wmEvent *event, int type)
|
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
|
|
|
wmGesture *gesture= MEM_callocN(sizeof(wmGesture), "new gesture");
|
2008-12-18 02:56:48 +00:00
|
|
|
wmWindow *window= CTX_wm_window(C);
|
2009-01-06 10:09:39 +00:00
|
|
|
ARegion *ar= CTX_wm_region(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
|
|
|
int sx, sy;
|
|
|
|
|
2008-12-18 02:56:48 +00:00
|
|
|
BLI_addtail(&window->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
|
|
|
|
|
|
|
gesture->type= type;
|
2008-11-24 10:45:36 +00:00
|
|
|
gesture->event_type= event->type;
|
2009-01-06 10:09:39 +00:00
|
|
|
gesture->swinid= ar->swinid; /* means only in area-region context! */
|
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-18 02:56:48 +00:00
|
|
|
wm_subwindow_getorigin(window, gesture->swinid, &sx, &sy);
|
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-21 16:24:19 +00:00
|
|
|
if( ELEM4(type, WM_GESTURE_RECT, WM_GESTURE_CROSS_RECT, WM_GESTURE_TWEAK, WM_GESTURE_CIRCLE)) {
|
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
|
|
|
rcti *rect= MEM_callocN(sizeof(rcti), "gesture rect new");
|
|
|
|
|
|
|
|
gesture->customdata= rect;
|
|
|
|
rect->xmin= event->x - sx;
|
|
|
|
rect->ymin= event->y - sy;
|
2009-11-05 17:32:06 +00:00
|
|
|
if(type==WM_GESTURE_CIRCLE) {
|
|
|
|
#ifdef GESTURE_MEMORY
|
|
|
|
rect->xmax= circle_select_size;
|
|
|
|
#else
|
2008-12-21 16:24:19 +00:00
|
|
|
rect->xmax= 25; // XXX temp
|
2009-11-05 17:32:06 +00:00
|
|
|
#endif
|
|
|
|
} else {
|
2008-12-21 16:24:19 +00:00
|
|
|
rect->xmax= event->x - sx;
|
|
|
|
rect->ymax= event->y - sy;
|
|
|
|
}
|
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;
|
|
|
|
gesture->customdata= lasso= MEM_callocN(2*sizeof(short)*WM_LASSO_MAX_POINTS, "lasso points");
|
|
|
|
lasso[0] = event->x - sx;
|
|
|
|
lasso[1] = event->y - sy;
|
|
|
|
gesture->points= 1;
|
|
|
|
}
|
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
|
|
|
{
|
2008-12-18 02:56:48 +00:00
|
|
|
BLI_remlink(&CTX_wm_window(C)->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);
|
|
|
|
MEM_freeN(gesture);
|
2008-01-19 17:54:05 +00:00
|
|
|
}
|
|
|
|
|
2008-11-24 10:45:36 +00:00
|
|
|
/* tweak and line gestures */
|
|
|
|
#define TWEAK_THRESHOLD 10
|
|
|
|
int wm_gesture_evaluate(bContext *C, wmGesture *gesture)
|
|
|
|
{
|
|
|
|
if(gesture->type==WM_GESTURE_TWEAK) {
|
|
|
|
rcti *rect= gesture->customdata;
|
|
|
|
int dx= rect->xmax - rect->xmin;
|
|
|
|
int dy= rect->ymax - rect->ymin;
|
|
|
|
if(ABS(dx)+ABS(dy) > TWEAK_THRESHOLD) {
|
2008-11-24 14:16:04 +00:00
|
|
|
int theta= (int)floor(4.0f*atan2((float)dy, (float)dx)/M_PI + 0.5);
|
2008-11-24 10:45:36 +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;
|
|
|
|
|
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 */
|
|
|
|
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");
|
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
|
|
|
#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
|
|
|
|
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
|
|
|
static void wm_gesture_draw_rect(wmWindow *win, wmGesture *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
|
|
|
rcti *rect= (rcti *)gt->customdata;
|
|
|
|
|
|
|
|
glEnable(GL_LINE_STIPPLE);
|
|
|
|
glColor3ub(0, 0, 0);
|
2008-11-24 10:45:36 +00:00
|
|
|
glLineStipple(1, 0xCCCC);
|
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
|
|
|
sdrawbox(rect->xmin, rect->ymin, rect->xmax, rect->ymax);
|
|
|
|
glColor3ub(255, 255, 255);
|
|
|
|
glLineStipple(1, 0x3333);
|
|
|
|
sdrawbox(rect->xmin, rect->ymin, rect->xmax, rect->ymax);
|
|
|
|
glDisable(GL_LINE_STIPPLE);
|
2008-01-19 17:54:05 +00:00
|
|
|
}
|
|
|
|
|
2008-11-24 10:45:36 +00:00
|
|
|
static void wm_gesture_draw_line(wmWindow *win, wmGesture *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
|
|
|
rcti *rect= (rcti *)gt->customdata;
|
|
|
|
|
|
|
|
glEnable(GL_LINE_STIPPLE);
|
|
|
|
glColor3ub(0, 0, 0);
|
|
|
|
glLineStipple(1, 0xAAAA);
|
2008-11-24 10:45:36 +00:00
|
|
|
sdrawline(rect->xmin, rect->ymin, rect->xmax, rect->ymax);
|
|
|
|
glColor3ub(255, 255, 255);
|
|
|
|
glLineStipple(1, 0x5555);
|
|
|
|
sdrawline(rect->xmin, rect->ymin, rect->xmax, rect->ymax);
|
|
|
|
|
|
|
|
glDisable(GL_LINE_STIPPLE);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2008-12-21 16:24:19 +00:00
|
|
|
static void wm_gesture_draw_circle(wmWindow *win, wmGesture *gt)
|
|
|
|
{
|
|
|
|
rcti *rect= (rcti *)gt->customdata;
|
|
|
|
|
|
|
|
glTranslatef((float)rect->xmin, (float)rect->ymin, 0.0f);
|
|
|
|
|
|
|
|
glEnable(GL_LINE_STIPPLE);
|
|
|
|
glColor3ub(0, 0, 0);
|
|
|
|
glLineStipple(1, 0xAAAA);
|
|
|
|
glutil_draw_lined_arc(0.0, M_PI*2.0, rect->xmax, 40);
|
|
|
|
glColor3ub(255, 255, 255);
|
|
|
|
glLineStipple(1, 0x5555);
|
|
|
|
glutil_draw_lined_arc(0.0, M_PI*2.0, rect->xmax, 40);
|
|
|
|
|
|
|
|
glDisable(GL_LINE_STIPPLE);
|
|
|
|
glTranslatef((float)-rect->xmin, (float)-rect->ymin, 0.0f);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2009-01-02 14:11:18 +00:00
|
|
|
static void wm_gesture_draw_lasso(wmWindow *win, wmGesture *gt)
|
|
|
|
{
|
|
|
|
short *lasso= (short *)gt->customdata;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
glEnable(GL_LINE_STIPPLE);
|
|
|
|
glColor3ub(0, 0, 0);
|
|
|
|
glLineStipple(1, 0xAAAA);
|
|
|
|
glBegin(GL_LINE_STRIP);
|
|
|
|
for(i=0; i<gt->points; i++, lasso+=2)
|
|
|
|
glVertex2sv(lasso);
|
2009-02-07 14:03:34 +00:00
|
|
|
if(gt->type==WM_GESTURE_LASSO)
|
|
|
|
glVertex2sv((short *)gt->customdata);
|
2009-01-02 14:11:18 +00:00
|
|
|
glEnd();
|
|
|
|
|
|
|
|
glColor3ub(255, 255, 255);
|
|
|
|
glLineStipple(1, 0x5555);
|
|
|
|
glBegin(GL_LINE_STRIP);
|
|
|
|
lasso= (short *)gt->customdata;
|
|
|
|
for(i=0; i<gt->points; i++, lasso+=2)
|
|
|
|
glVertex2sv(lasso);
|
2009-02-07 14:03:34 +00:00
|
|
|
if(gt->type==WM_GESTURE_LASSO)
|
|
|
|
glVertex2sv((short *)gt->customdata);
|
2009-01-02 14:11:18 +00:00
|
|
|
glEnd();
|
|
|
|
|
|
|
|
glDisable(GL_LINE_STIPPLE);
|
|
|
|
|
|
|
|
}
|
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)
|
|
|
|
{
|
|
|
|
rcti *rect= (rcti *)gt->customdata;
|
|
|
|
|
|
|
|
glEnable(GL_LINE_STIPPLE);
|
|
|
|
glColor3ub(0, 0, 0);
|
|
|
|
glLineStipple(1, 0xCCCC);
|
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
|
|
|
sdrawline(rect->xmin - win->sizex, rect->ymin, rect->xmin + win->sizex, rect->ymin);
|
|
|
|
sdrawline(rect->xmin, rect->ymin - win->sizey, rect->xmin, rect->ymin + win->sizey);
|
|
|
|
|
|
|
|
glColor3ub(255, 255, 255);
|
|
|
|
glLineStipple(1, 0x3333);
|
|
|
|
sdrawline(rect->xmin - win->sizex, rect->ymin, rect->xmin + win->sizex, rect->ymin);
|
|
|
|
sdrawline(rect->xmin, rect->ymin - win->sizey, rect->xmin, rect->ymin + win->sizey);
|
|
|
|
glDisable(GL_LINE_STIPPLE);
|
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
|
|
|
{
|
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
|
|
|
wmGesture *gt= (wmGesture *)win->gesture.first;
|
|
|
|
|
|
|
|
for(; gt; gt= gt->next) {
|
|
|
|
/* all in subwindow space */
|
2008-12-19 14:14:43 +00:00
|
|
|
wmSubWindowSet(win, gt->swinid);
|
2009-12-17 19:55:08 +00:00
|
|
|
wmOrthoPixelSpace();
|
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
|
|
|
|
|
|
|
if(gt->type==WM_GESTURE_RECT)
|
|
|
|
wm_gesture_draw_rect(win, gt);
|
2008-11-24 10:45:36 +00:00
|
|
|
else if(gt->type==WM_GESTURE_TWEAK)
|
|
|
|
wm_gesture_draw_line(win, gt);
|
2008-12-21 16:24:19 +00:00
|
|
|
else if(gt->type==WM_GESTURE_CIRCLE)
|
|
|
|
wm_gesture_draw_circle(win, gt);
|
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
|
|
|
else if(gt->type==WM_GESTURE_CROSS_RECT) {
|
|
|
|
if(gt->mode==1)
|
|
|
|
wm_gesture_draw_rect(win, gt);
|
|
|
|
else
|
|
|
|
wm_gesture_draw_cross(win, gt);
|
|
|
|
}
|
2009-02-07 14:03:34 +00:00
|
|
|
else if(gt->type==WM_GESTURE_LINES)
|
|
|
|
wm_gesture_draw_lasso(win, gt);
|
2009-01-02 14:11:18 +00:00
|
|
|
else if(gt->type==WM_GESTURE_LASSO)
|
|
|
|
wm_gesture_draw_lasso(win, 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)
|
|
|
|
{
|
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
|
|
|
wmWindow *win= CTX_wm_window(C);
|
2008-12-27 16:09:56 +00:00
|
|
|
bScreen *screen= CTX_wm_screen(C);
|
|
|
|
ARegion *ar= CTX_wm_region(C);
|
|
|
|
|
|
|
|
if(screen)
|
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
|
|
|
screen->do_draw_gesture= 1;
|
|
|
|
if(ar && win->drawmethod != USER_DRAW_TRIPLE)
|
2008-12-27 16:09:56 +00:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
}
|
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
|
|
|
|