2011-02-23 11:52:22 +01:00
|
|
|
/*
|
2008-12-14 15:43:08 +01:00
|
|
|
* ***** 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,
|
2010-02-12 14:34:04 +01:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2008-12-14 15:43:08 +01:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-27 21:29:51 +01:00
|
|
|
/** \file blender/editors/space_sequencer/space_sequencer.c
|
|
|
|
* \ingroup spseq
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
#include <string.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include "DNA_scene_types.h"
|
2012-06-07 21:24:49 +02:00
|
|
|
#include "DNA_mask_types.h"
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
#include "BLI_blenlib.h"
|
2009-11-10 21:43:45 +01:00
|
|
|
#include "BLI_math.h"
|
2011-01-07 19:36:47 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2008-12-18 03:56:48 +01:00
|
|
|
#include "BKE_context.h"
|
2008-12-14 15:43:08 +01:00
|
|
|
#include "BKE_screen.h"
|
2009-12-13 15:56:45 +01:00
|
|
|
#include "BKE_sequencer.h"
|
2010-03-09 08:41:04 +01:00
|
|
|
#include "BKE_global.h"
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2011-02-14 18:55:27 +01:00
|
|
|
#include "ED_space_api.h"
|
|
|
|
#include "ED_sequencer.h"
|
2008-12-14 15:43:08 +01:00
|
|
|
#include "ED_screen.h"
|
2010-03-09 08:41:04 +01:00
|
|
|
#include "ED_view3d.h" /* only for sequencer view3d drawing callback */
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
#include "WM_api.h"
|
|
|
|
#include "WM_types.h"
|
|
|
|
|
|
|
|
#include "UI_resources.h"
|
|
|
|
#include "UI_view2d.h"
|
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
#include "IMB_imbuf.h"
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
#include "sequencer_intern.h" // own include
|
2008-12-14 15:43:08 +01:00
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
/**************************** common state *****************************/
|
|
|
|
|
|
|
|
static void sequencer_scopes_tag_refresh(ScrArea *sa)
|
|
|
|
{
|
|
|
|
SpaceSeq *sseq = (SpaceSeq *)sa->spacedata.first;
|
|
|
|
|
|
|
|
sseq->scopes.reference_ibuf = NULL;
|
|
|
|
}
|
|
|
|
|
2009-06-08 12:38:28 +02:00
|
|
|
/* ******************** manage regions ********************* */
|
|
|
|
|
|
|
|
ARegion *sequencer_has_buttons_region(ScrArea *sa)
|
|
|
|
{
|
|
|
|
ARegion *ar, *arnew;
|
2011-05-20 07:27:31 +02:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = BKE_area_find_region_type(sa, RGN_TYPE_UI);
|
2012-03-24 07:38:07 +01:00
|
|
|
if (ar) return ar;
|
2009-06-08 12:38:28 +02:00
|
|
|
|
|
|
|
/* add subdiv level; after header */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = BKE_area_find_region_type(sa, RGN_TYPE_HEADER);
|
2011-05-20 07:27:31 +02:00
|
|
|
|
2009-06-08 12:38:28 +02:00
|
|
|
/* is error! */
|
2012-03-30 00:26:11 +02:00
|
|
|
if (ar == NULL) return NULL;
|
2009-06-08 12:38:28 +02:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
arnew = MEM_callocN(sizeof(ARegion), "buttons for sequencer");
|
2009-06-08 12:38:28 +02:00
|
|
|
|
|
|
|
BLI_insertlinkafter(&sa->regionbase, ar, arnew);
|
2012-03-30 00:26:11 +02:00
|
|
|
arnew->regiontype = RGN_TYPE_UI;
|
|
|
|
arnew->alignment = RGN_ALIGN_RIGHT;
|
2009-06-08 12:38:28 +02:00
|
|
|
|
|
|
|
arnew->flag = RGN_FLAG_HIDDEN;
|
|
|
|
|
|
|
|
return arnew;
|
|
|
|
}
|
|
|
|
|
2011-02-14 18:55:27 +01:00
|
|
|
static ARegion *sequencer_find_region(ScrArea *sa, short type)
|
2009-12-14 22:42:25 +01:00
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
ARegion *ar = NULL;
|
2009-12-14 22:42:25 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
for (ar = sa->regionbase.first; ar; ar = ar->next)
|
|
|
|
if (ar->regiontype == type)
|
2009-12-14 22:42:25 +01:00
|
|
|
return ar;
|
|
|
|
|
|
|
|
return ar;
|
|
|
|
}
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* ******************** default callbacks for sequencer space ***************** */
|
|
|
|
|
2008-12-22 11:09:56 +01:00
|
|
|
static SpaceLink *sequencer_new(const bContext *C)
|
2008-12-14 15:43:08 +01:00
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
Scene *scene = CTX_data_scene(C);
|
2008-12-14 15:43:08 +01:00
|
|
|
ARegion *ar;
|
|
|
|
SpaceSeq *sseq;
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
sseq = MEM_callocN(sizeof(SpaceSeq), "initsequencer");
|
|
|
|
sseq->spacetype = SPACE_SEQ;
|
2008-12-14 15:43:08 +01:00
|
|
|
sseq->chanshown = 0;
|
2009-12-14 22:42:25 +01:00
|
|
|
sseq->view = SEQ_VIEW_SEQUENCE;
|
|
|
|
sseq->mainb = SEQ_DRAW_IMG_IMBUF;
|
2008-12-14 15:43:08 +01:00
|
|
|
/* header */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = MEM_callocN(sizeof(ARegion), "header for sequencer");
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
BLI_addtail(&sseq->regionbase, ar);
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->regiontype = RGN_TYPE_HEADER;
|
|
|
|
ar->alignment = RGN_ALIGN_BOTTOM;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2009-06-08 12:38:28 +02:00
|
|
|
/* buttons/list view */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = MEM_callocN(sizeof(ARegion), "buttons for sequencer");
|
2009-06-08 12:38:28 +02:00
|
|
|
|
|
|
|
BLI_addtail(&sseq->regionbase, ar);
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->regiontype = RGN_TYPE_UI;
|
|
|
|
ar->alignment = RGN_ALIGN_RIGHT;
|
2009-06-08 12:38:28 +02:00
|
|
|
ar->flag = RGN_FLAG_HIDDEN;
|
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
/* preview area */
|
2010-02-07 20:07:56 +01:00
|
|
|
/* NOTE: if you change values here, also change them in sequencer_init_preview_region */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = MEM_callocN(sizeof(ARegion), "preview area for sequencer");
|
2009-12-14 22:42:25 +01:00
|
|
|
BLI_addtail(&sseq->regionbase, ar);
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->regiontype = RGN_TYPE_PREVIEW;
|
|
|
|
ar->alignment = RGN_ALIGN_TOP;
|
2009-12-14 22:42:25 +01:00
|
|
|
ar->flag |= RGN_FLAG_HIDDEN;
|
2010-02-07 20:07:56 +01:00
|
|
|
/* for now, aspect ratio should be maintained, and zoom is clamped within sane default limits */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.keepzoom = V2D_KEEPASPECT | V2D_KEEPZOOM;
|
|
|
|
ar->v2d.minzoom = 0.00001f;
|
|
|
|
ar->v2d.maxzoom = 100000.0f;
|
2012-03-24 03:51:46 +01:00
|
|
|
ar->v2d.tot.xmin = -960.0f; /* 1920 width centered */
|
|
|
|
ar->v2d.tot.ymin = -540.0f; /* 1080 height centered */
|
|
|
|
ar->v2d.tot.xmax = 960.0f;
|
|
|
|
ar->v2d.tot.ymax = 540.0f;
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.min[0] = 0.0f;
|
|
|
|
ar->v2d.min[1] = 0.0f;
|
|
|
|
ar->v2d.max[0] = 12000.0f;
|
|
|
|
ar->v2d.max[1] = 12000.0f;
|
|
|
|
ar->v2d.cur = ar->v2d.tot;
|
|
|
|
ar->v2d.align = V2D_ALIGN_FREE;
|
|
|
|
ar->v2d.keeptot = V2D_KEEPTOT_FREE;
|
2010-02-07 20:07:56 +01:00
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* main area */
|
2012-03-30 00:26:11 +02:00
|
|
|
ar = MEM_callocN(sizeof(ARegion), "main area for sequencer");
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
BLI_addtail(&sseq->regionbase, ar);
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->regiontype = RGN_TYPE_WINDOW;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
|
2008-12-22 11:09:56 +01:00
|
|
|
/* seq space goes from (0,8) to (0, efra) */
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-24 03:51:46 +01:00
|
|
|
ar->v2d.tot.xmin = 0.0f;
|
|
|
|
ar->v2d.tot.ymin = 0.0f;
|
|
|
|
ar->v2d.tot.xmax = scene->r.efra;
|
|
|
|
ar->v2d.tot.ymax = 8.0f;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.cur = ar->v2d.tot;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.min[0] = 10.0f;
|
|
|
|
ar->v2d.min[1] = 0.5f;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.max[0] = MAXFRAMEF;
|
|
|
|
ar->v2d.max[1] = MAXSEQ;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
ar->v2d.minzoom = 0.01f;
|
|
|
|
ar->v2d.maxzoom = 100.0f;
|
|
|
|
|
|
|
|
ar->v2d.scroll |= (V2D_SCROLL_BOTTOM | V2D_SCROLL_SCALE_HORIZONTAL);
|
|
|
|
ar->v2d.scroll |= (V2D_SCROLL_LEFT | V2D_SCROLL_SCALE_VERTICAL);
|
|
|
|
ar->v2d.keepzoom = 0;
|
|
|
|
ar->v2d.keeptot = 0;
|
|
|
|
ar->v2d.align = V2D_ALIGN_NO_NEG_Y;
|
2009-12-14 22:42:25 +01:00
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
return (SpaceLink *)sseq;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* not spacelink itself */
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
static void sequencer_free(SpaceLink *sl)
|
2008-12-14 15:43:08 +01:00
|
|
|
{
|
2012-09-26 22:26:31 +02:00
|
|
|
SpaceSeq *sseq = (SpaceSeq *) sl;
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
SequencerScopes *scopes = &sseq->scopes;
|
|
|
|
|
2012-05-05 16:03:12 +02:00
|
|
|
// XXX if (sseq->gpd) BKE_gpencil_free(sseq->gpd);
|
2008-12-14 15:43:08 +01:00
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
if (scopes->zebra_ibuf)
|
|
|
|
IMB_freeImBuf(scopes->zebra_ibuf);
|
|
|
|
|
|
|
|
if (scopes->waveform_ibuf)
|
|
|
|
IMB_freeImBuf(scopes->waveform_ibuf);
|
|
|
|
|
|
|
|
if (scopes->sep_waveform_ibuf)
|
|
|
|
IMB_freeImBuf(scopes->sep_waveform_ibuf);
|
|
|
|
|
|
|
|
if (scopes->vector_ibuf)
|
|
|
|
IMB_freeImBuf(scopes->vector_ibuf);
|
|
|
|
|
|
|
|
if (scopes->histogram_ibuf)
|
|
|
|
IMB_freeImBuf(scopes->histogram_ibuf);
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* spacetype; init callback */
|
2010-10-16 10:03:28 +02:00
|
|
|
static void sequencer_init(struct wmWindowManager *UNUSED(wm), ScrArea *UNUSED(sa))
|
2008-12-14 15:43:08 +01: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 19:18:21 +01:00
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
2011-09-05 21:34:27 +02:00
|
|
|
static void sequencer_refresh(const bContext *C, ScrArea *sa)
|
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
wmWindowManager *wm = CTX_wm_manager(C);
|
|
|
|
wmWindow *window = CTX_wm_window(C);
|
|
|
|
SpaceSeq *sseq = (SpaceSeq *)sa->spacedata.first;
|
|
|
|
ARegion *ar_main = sequencer_find_region(sa, RGN_TYPE_WINDOW);
|
|
|
|
ARegion *ar_preview = sequencer_find_region(sa, RGN_TYPE_PREVIEW);
|
|
|
|
int view_changed = 0;
|
2011-09-05 21:34:27 +02:00
|
|
|
|
|
|
|
switch (sseq->view) {
|
|
|
|
case SEQ_VIEW_SEQUENCE:
|
|
|
|
if (ar_main && (ar_main->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_main->flag &= ~RGN_FLAG_HIDDEN;
|
|
|
|
ar_main->v2d.flag &= ~V2D_IS_INITIALISED;
|
2012-03-30 00:26:11 +02:00
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
if (ar_preview && !(ar_preview->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_preview->flag |= RGN_FLAG_HIDDEN;
|
|
|
|
ar_preview->v2d.flag &= ~V2D_IS_INITIALISED;
|
2012-03-30 00:26:11 +02:00
|
|
|
WM_event_remove_handlers((bContext *)C, &ar_preview->handlers);
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
2011-09-19 15:12:54 +02:00
|
|
|
if (ar_main && ar_main->alignment != RGN_ALIGN_NONE) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_main->alignment = RGN_ALIGN_NONE;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
2011-09-19 15:12:54 +02:00
|
|
|
if (ar_preview && ar_preview->alignment != RGN_ALIGN_NONE) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_preview->alignment = RGN_ALIGN_NONE;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case SEQ_VIEW_PREVIEW:
|
|
|
|
if (ar_main && !(ar_main->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_main->flag |= RGN_FLAG_HIDDEN;
|
|
|
|
ar_main->v2d.flag &= ~V2D_IS_INITIALISED;
|
2012-03-30 00:26:11 +02:00
|
|
|
WM_event_remove_handlers((bContext *)C, &ar_main->handlers);
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
if (ar_preview && (ar_preview->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_preview->flag &= ~RGN_FLAG_HIDDEN;
|
|
|
|
ar_preview->v2d.flag &= ~V2D_IS_INITIALISED;
|
|
|
|
ar_preview->v2d.cur = ar_preview->v2d.tot;
|
2012-03-30 00:26:11 +02:00
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
2011-09-19 15:12:54 +02:00
|
|
|
if (ar_main && ar_main->alignment != RGN_ALIGN_NONE) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_main->alignment = RGN_ALIGN_NONE;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
2011-09-19 15:12:54 +02:00
|
|
|
if (ar_preview && ar_preview->alignment != RGN_ALIGN_NONE) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_preview->alignment = RGN_ALIGN_NONE;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case SEQ_VIEW_SEQUENCE_PREVIEW:
|
|
|
|
if (ar_main && (ar_main->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_main->flag &= ~RGN_FLAG_HIDDEN;
|
|
|
|
ar_main->v2d.flag &= ~V2D_IS_INITIALISED;
|
2012-03-30 00:26:11 +02:00
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
if (ar_preview && (ar_preview->flag & RGN_FLAG_HIDDEN)) {
|
|
|
|
ar_preview->flag &= ~RGN_FLAG_HIDDEN;
|
|
|
|
ar_preview->v2d.flag &= ~V2D_IS_INITIALISED;
|
|
|
|
ar_preview->v2d.cur = ar_preview->v2d.tot;
|
2012-03-30 00:26:11 +02:00
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
2011-09-19 15:12:54 +02:00
|
|
|
if (ar_main && ar_main->alignment != RGN_ALIGN_NONE) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_main->alignment = RGN_ALIGN_NONE;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
if (ar_preview && ar_preview->alignment != RGN_ALIGN_TOP) {
|
2012-03-30 00:26:11 +02:00
|
|
|
ar_preview->alignment = RGN_ALIGN_TOP;
|
|
|
|
view_changed = 1;
|
2011-09-05 21:34:27 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2012-03-24 07:38:07 +01:00
|
|
|
if (view_changed) {
|
2011-09-05 21:34:27 +02:00
|
|
|
ED_area_initialize(wm, window, sa);
|
|
|
|
ED_area_tag_redraw(sa);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
static SpaceLink *sequencer_duplicate(SpaceLink *sl)
|
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
SpaceSeq *sseqn = MEM_dupallocN(sl);
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
/* clear or remove stuff from old */
|
|
|
|
// XXX sseq->gpd= gpencil_data_duplicate(sseq->gpd);
|
|
|
|
|
|
|
|
return (SpaceLink *)sseqn;
|
|
|
|
}
|
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
static void sequencer_listener(ScrArea *sa, wmNotifier *wmn)
|
|
|
|
{
|
|
|
|
/* context changes */
|
|
|
|
switch (wmn->category) {
|
|
|
|
case NC_SCENE:
|
|
|
|
switch (wmn->data) {
|
|
|
|
case ND_FRAME:
|
|
|
|
case ND_SEQUENCER:
|
|
|
|
sequencer_scopes_tag_refresh(sa);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case NC_SPACE:
|
|
|
|
if (wmn->data == ND_SPACE_SEQUENCER)
|
|
|
|
sequencer_scopes_tag_refresh(sa);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
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 19:18:21 +01:00
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
/* *********************** sequencer (main) region ************************ */
|
2008-12-14 15:43:08 +01:00
|
|
|
/* add handlers, stuff you only do once or on area/region changes */
|
|
|
|
static void sequencer_main_area_init(wmWindowManager *wm, ARegion *ar)
|
|
|
|
{
|
2009-09-17 23:36:02 +02:00
|
|
|
wmKeyMap *keymap;
|
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 19:18:21 +01:00
|
|
|
ListBase *lb;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2008-12-17 11:25:02 +01:00
|
|
|
UI_view2d_region_reinit(&ar->v2d, V2D_COMMONVIEW_CUSTOM, ar->winx, ar->winy);
|
2012-07-24 11:53:29 +02:00
|
|
|
|
|
|
|
// keymap = WM_keymap_find(wm->defaultconf, "Mask Editing", 0, 0);
|
|
|
|
// WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
|
|
|
|
2012-03-24 03:51:46 +01:00
|
|
|
keymap = WM_keymap_find(wm->defaultconf, "SequencerCommon", SPACE_SEQ, 0);
|
2009-12-14 22:42:25 +01:00
|
|
|
WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* own keymap */
|
2012-03-24 03:51:46 +01:00
|
|
|
keymap = WM_keymap_find(wm->defaultconf, "Sequencer", SPACE_SEQ, 0);
|
2008-12-14 15:43:08 +01:00
|
|
|
WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
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 19:18:21 +01:00
|
|
|
|
|
|
|
/* add drop boxes */
|
2012-03-30 00:26:11 +02:00
|
|
|
lb = WM_dropboxmap_find("Sequencer", SPACE_SEQ, RGN_TYPE_WINDOW);
|
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 19:18:21 +01:00
|
|
|
|
|
|
|
WM_event_add_dropbox_handler(&ar->handlers, lb);
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
2009-11-26 13:22:43 +01:00
|
|
|
static void sequencer_main_area_draw(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-12-15 12:27:46 +01:00
|
|
|
// ScrArea *sa= CTX_wm_area(C);
|
2009-11-26 13:22:43 +01:00
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
/* NLE - strip editing timeline interface */
|
|
|
|
draw_timeline_seq(C, ar);
|
2009-11-26 13:22:43 +01: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 19:18:21 +01:00
|
|
|
/* ************* dropboxes ************* */
|
|
|
|
|
2012-06-14 06:57:42 +02:00
|
|
|
static int image_drop_poll(bContext *C, wmDrag *drag, wmEvent *event)
|
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 19:18:21 +01:00
|
|
|
{
|
2012-06-14 06:57:42 +02:00
|
|
|
ARegion *ar = CTX_wm_region(C);
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
|
|
|
int hand;
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
if (drag->type == WM_DRAG_PATH)
|
|
|
|
if (ELEM(drag->icon, ICON_FILE_IMAGE, ICON_FILE_BLANK)) /* rule might not work? */
|
2012-06-14 06:57:42 +02:00
|
|
|
if (find_nearest_seq(scene, &ar->v2d, &hand, event->mval) == NULL)
|
|
|
|
return 1;
|
|
|
|
|
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 19:18:21 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-06-14 06:57:42 +02:00
|
|
|
static int movie_drop_poll(bContext *C, wmDrag *drag, wmEvent *event)
|
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 19:18:21 +01:00
|
|
|
{
|
2012-06-14 06:57:42 +02:00
|
|
|
ARegion *ar = CTX_wm_region(C);
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
|
|
|
int hand;
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
if (drag->type == WM_DRAG_PATH)
|
|
|
|
if (ELEM3(drag->icon, 0, ICON_FILE_MOVIE, ICON_FILE_BLANK)) /* rule might not work? */
|
2012-06-14 06:57:42 +02:00
|
|
|
if (find_nearest_seq(scene, &ar->v2d, &hand, event->mval) == NULL)
|
|
|
|
return 1;
|
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 19:18:21 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-06-14 06:57:42 +02:00
|
|
|
static int sound_drop_poll(bContext *C, wmDrag *drag, wmEvent *event)
|
2010-02-09 10:31:45 +01:00
|
|
|
{
|
2012-06-14 06:57:42 +02:00
|
|
|
ARegion *ar = CTX_wm_region(C);
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
|
|
|
int hand;
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
if (drag->type == WM_DRAG_PATH)
|
|
|
|
if (ELEM(drag->icon, ICON_FILE_SOUND, ICON_FILE_BLANK)) /* rule might not work? */
|
2012-06-14 06:57:42 +02:00
|
|
|
if (find_nearest_seq(scene, &ar->v2d, &hand, event->mval) == NULL)
|
|
|
|
return 1;
|
2010-02-09 10:31:45 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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 19:18:21 +01:00
|
|
|
static void sequencer_drop_copy(wmDrag *drag, wmDropBox *drop)
|
|
|
|
{
|
|
|
|
/* copy drag path to properties */
|
2012-03-24 07:38:07 +01:00
|
|
|
if (RNA_struct_find_property(drop->ptr, "filepath"))
|
2010-07-21 19:37:40 +02:00
|
|
|
RNA_string_set(drop->ptr, "filepath", drag->path);
|
|
|
|
|
2012-03-24 07:38:07 +01:00
|
|
|
if (RNA_struct_find_property(drop->ptr, "directory")) {
|
2010-07-21 19:37:40 +02:00
|
|
|
PointerRNA itemptr;
|
|
|
|
char dir[FILE_MAX], file[FILE_MAX];
|
|
|
|
|
2011-10-15 05:56:05 +02:00
|
|
|
BLI_split_dirfile(drag->path, dir, file, sizeof(dir), sizeof(file));
|
2010-07-21 19:37:40 +02:00
|
|
|
|
|
|
|
RNA_string_set(drop->ptr, "directory", dir);
|
|
|
|
|
2010-12-11 21:01:34 +01:00
|
|
|
RNA_collection_clear(drop->ptr, "files");
|
2010-07-21 19:37:40 +02:00
|
|
|
RNA_collection_add(drop->ptr, "files", &itemptr);
|
|
|
|
RNA_string_set(&itemptr, "name", file);
|
|
|
|
}
|
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 19:18:21 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* this region dropbox definition */
|
|
|
|
static void sequencer_dropboxes(void)
|
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
ListBase *lb = WM_dropboxmap_find("Sequencer", SPACE_SEQ, RGN_TYPE_WINDOW);
|
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 19:18:21 +01:00
|
|
|
|
|
|
|
WM_dropbox_add(lb, "SEQUENCER_OT_image_strip_add", image_drop_poll, sequencer_drop_copy);
|
|
|
|
WM_dropbox_add(lb, "SEQUENCER_OT_movie_strip_add", movie_drop_poll, sequencer_drop_copy);
|
2010-02-09 10:31:45 +01:00
|
|
|
WM_dropbox_add(lb, "SEQUENCER_OT_sound_strip_add", sound_drop_poll, sequencer_drop_copy);
|
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 19:18:21 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ************* end drop *********** */
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-06-07 21:24:49 +02:00
|
|
|
const char *sequencer_context_dir[] = {"edit_mask", NULL};
|
|
|
|
|
|
|
|
static int sequencer_context(const bContext *C, const char *member, bContextDataResult *result)
|
|
|
|
{
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
|
|
|
|
|
|
|
if (CTX_data_dir(member)) {
|
|
|
|
CTX_data_dir_set(result, sequencer_context_dir);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else if (CTX_data_equals(member, "edit_mask")) {
|
2012-07-24 11:53:29 +02:00
|
|
|
Mask *mask = BKE_sequencer_mask_get(scene);
|
|
|
|
if (mask) {
|
|
|
|
CTX_data_id_pointer_set(result, &mask->id);
|
2012-06-07 21:24:49 +02:00
|
|
|
}
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* add handlers, stuff you only do once or on area/region changes */
|
2010-10-16 10:03:28 +02:00
|
|
|
static void sequencer_header_area_init(wmWindowManager *UNUSED(wm), ARegion *ar)
|
2008-12-14 15:43:08 +01:00
|
|
|
{
|
2009-06-08 18:48:12 +02:00
|
|
|
ED_region_header_init(ar);
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_header_area_draw(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-06-08 18:48:12 +02:00
|
|
|
ED_region_header(C, ar);
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_main_area_listener(ARegion *ar, wmNotifier *wmn)
|
|
|
|
{
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
/* context changes */
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->category) {
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
case NC_SCENE:
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->data) {
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
case ND_FRAME:
|
2010-06-26 21:17:48 +02:00
|
|
|
case ND_FRAME_RANGE:
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
case ND_MARKERS:
|
2010-09-28 00:01:06 +02:00
|
|
|
case ND_RENDER_OPTIONS: /* for FPS and FPS Base */
|
2009-01-21 08:01:20 +01:00
|
|
|
case ND_SEQUENCER:
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2.5
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdates
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
2009-09-04 22:51:09 +02:00
|
|
|
case NC_SPACE:
|
2012-03-24 07:38:07 +01:00
|
|
|
if (wmn->data == ND_SPACE_SEQUENCER)
|
2.5
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdates
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
2009-09-04 22:51:09 +02:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
2009-12-10 10:58:10 +01:00
|
|
|
case NC_ID:
|
2012-03-24 07:38:07 +01:00
|
|
|
if (wmn->action == NA_RENAME)
|
2009-12-14 00:51:41 +01:00
|
|
|
ED_region_tag_redraw(ar);
|
2009-12-10 10:58:10 +01:00
|
|
|
break;
|
2012-07-03 17:01:54 +02:00
|
|
|
case NC_SCREEN:
|
|
|
|
if (ELEM(wmn->data, ND_SCREENCAST, ND_ANIMPLAY))
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
Added back some functionality to the sequencer
- removed static vars _last_seq, last_imagename and last_sounddir, replacing them with with vars in the "Editing" struct. didnt manage to get the active sequence to load so currently thats lost when loading.
- removed flag SEQ_ACTIVE
- Added operators cut, mute, unmute, deselect_all, select_invert, select, select_more, select_less, select_pick_linked, select_linked and borderselect.
2009-01-19 22:42:18 +01:00
|
|
|
}
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
/* *********************** preview region ************************ */
|
|
|
|
static void sequencer_preview_area_init(wmWindowManager *wm, ARegion *ar)
|
|
|
|
{
|
|
|
|
wmKeyMap *keymap;
|
2010-02-07 20:07:56 +01:00
|
|
|
|
|
|
|
UI_view2d_region_reinit(&ar->v2d, V2D_COMMONVIEW_CUSTOM, ar->winx, ar->winy);
|
2009-12-14 22:42:25 +01:00
|
|
|
|
2012-07-24 11:53:29 +02:00
|
|
|
// keymap = WM_keymap_find(wm->defaultconf, "Mask Editing", 0, 0);
|
|
|
|
// WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
|
|
|
|
2012-03-24 03:51:46 +01:00
|
|
|
keymap = WM_keymap_find(wm->defaultconf, "SequencerCommon", SPACE_SEQ, 0);
|
2009-12-14 22:42:25 +01:00
|
|
|
WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
|
|
|
|
|
|
|
/* own keymap */
|
2012-03-24 03:51:46 +01:00
|
|
|
keymap = WM_keymap_find(wm->defaultconf, "SequencerPreview", SPACE_SEQ, 0);
|
2009-12-14 22:42:25 +01:00
|
|
|
WM_event_add_keymap_handler_bb(&ar->handlers, keymap, &ar->v2d.mask, &ar->winrct);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_preview_area_draw(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
ScrArea *sa = CTX_wm_area(C);
|
|
|
|
SpaceSeq *sseq = sa->spacedata.first;
|
|
|
|
Scene *scene = CTX_data_scene(C);
|
2012-08-12 15:24:29 +02:00
|
|
|
int show_split = scene->ed && scene->ed->over_flag & SEQ_EDIT_OVERLAY_SHOW && sseq->mainb == SEQ_DRAW_IMG_IMBUF;
|
2009-12-14 22:42:25 +01:00
|
|
|
|
|
|
|
/* XXX temp fix for wrong setting in sseq->mainb */
|
|
|
|
if (sseq->mainb == SEQ_DRAW_SEQUENCE) sseq->mainb = SEQ_DRAW_IMG_IMBUF;
|
2010-07-08 12:03:29 +02:00
|
|
|
|
2012-08-12 15:24:29 +02:00
|
|
|
if (!show_split || sseq->overlay_type != SEQ_DRAW_OVERLAY_REFERENCE)
|
|
|
|
draw_image_seq(C, scene, ar, sseq, scene->r.cfra, 0, FALSE);
|
2010-07-08 12:03:29 +02:00
|
|
|
|
2012-08-12 15:24:29 +02:00
|
|
|
if (show_split && sseq->overlay_type != SEQ_DRAW_OVERLAY_CURRENT) {
|
2010-07-08 12:03:29 +02:00
|
|
|
int over_cfra;
|
|
|
|
|
2012-03-24 07:38:07 +01:00
|
|
|
if (scene->ed->over_flag & SEQ_EDIT_OVERLAY_ABS)
|
2012-03-30 00:26:11 +02:00
|
|
|
over_cfra = scene->ed->over_cfra;
|
2010-07-08 12:03:29 +02:00
|
|
|
else
|
2012-03-30 00:26:11 +02:00
|
|
|
over_cfra = scene->r.cfra + scene->ed->over_ofs;
|
2010-07-08 12:03:29 +02:00
|
|
|
|
2012-08-12 15:24:29 +02:00
|
|
|
if (over_cfra != scene->r.cfra || sseq->overlay_type != SEQ_DRAW_OVERLAY_RECT)
|
|
|
|
draw_image_seq(C, scene, ar, sseq, scene->r.cfra, over_cfra - scene->r.cfra, TRUE);
|
2010-07-08 12:03:29 +02:00
|
|
|
}
|
|
|
|
|
2009-12-14 22:42:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_preview_area_listener(ARegion *ar, wmNotifier *wmn)
|
|
|
|
{
|
|
|
|
/* context changes */
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->category) {
|
2012-06-11 02:21:50 +02:00
|
|
|
case NC_SCREEN:
|
|
|
|
if (wmn->data == ND_GPENCIL) {
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
}
|
|
|
|
break;
|
2009-12-14 22:42:25 +01:00
|
|
|
case NC_SCENE:
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->data) {
|
2009-12-14 22:42:25 +01:00
|
|
|
case ND_FRAME:
|
|
|
|
case ND_MARKERS:
|
|
|
|
case ND_SEQUENCER:
|
2012-04-30 00:25:31 +02:00
|
|
|
case ND_RENDER_OPTIONS:
|
2009-12-14 22:42:25 +01:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case NC_SPACE:
|
2012-03-24 07:38:07 +01:00
|
|
|
if (wmn->data == ND_SPACE_SEQUENCER)
|
2009-12-14 22:42:25 +01:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
|
|
|
case NC_ID:
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->data) {
|
2009-12-14 22:42:25 +01:00
|
|
|
case NA_RENAME:
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2012-06-07 20:24:36 +02:00
|
|
|
|
|
|
|
case NC_MASK:
|
|
|
|
if (wmn->action == NA_EDITED) {
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
}
|
|
|
|
break;
|
2009-12-14 22:42:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-08 12:38:28 +02:00
|
|
|
/* *********************** buttons region ************************ */
|
|
|
|
|
|
|
|
/* add handlers, stuff you only do once or on area/region changes */
|
|
|
|
static void sequencer_buttons_area_init(wmWindowManager *wm, ARegion *ar)
|
|
|
|
{
|
|
|
|
|
|
|
|
ED_region_panels_init(wm, ar);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_buttons_area_draw(const bContext *C, ARegion *ar)
|
|
|
|
{
|
2009-07-30 00:57:53 +02:00
|
|
|
ED_region_panels(C, ar, 1, NULL, -1);
|
2009-06-08 12:38:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static void sequencer_buttons_area_listener(ARegion *ar, wmNotifier *wmn)
|
|
|
|
{
|
|
|
|
/* context changes */
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->category) {
|
2012-06-11 02:21:50 +02:00
|
|
|
case NC_SCREEN:
|
|
|
|
if (wmn->data == ND_GPENCIL) {
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
}
|
|
|
|
break;
|
2009-10-19 12:07:19 +02:00
|
|
|
case NC_SCENE:
|
2012-03-30 00:26:11 +02:00
|
|
|
switch (wmn->data) {
|
|
|
|
case ND_FRAME:
|
|
|
|
case ND_SEQUENCER:
|
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
2.5
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdates
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
2009-09-04 22:51:09 +02:00
|
|
|
case NC_SPACE:
|
2012-03-24 07:38:07 +01:00
|
|
|
if (wmn->data == ND_SPACE_SEQUENCER)
|
2.5
Notifiers
---------
Various fixes for wrong use of notifiers, and some new notifiers
to make things a bit more clear and consistent, with two notable
changes:
* Geometry changes are now done with NC_GEOM, rather than
NC_OBJECT|ND_GEOM_, so an object does need to be available.
* Space data now use NC_SPACE|ND_SPACE_*, instead of data
notifiers or even NC_WINDOW in some cases. Note that NC_SPACE
should only be used for notifying about changes in space data,
we don't want to go back to allqueue(REDRAW..).
Depsgraph
---------
The dependency graph now has a different flush call:
DAG_object_flush_update(scene, ob, flag)
is replaced by:
DAG_id_flush_update(id, flag)
It still works basically the same, one difference is that it now
also accepts object data (e.g. Mesh), again to avoid requiring an
Object to be available. Other ID types will simply do nothing at
the moment.
Docs
----
I made some guidelines for how/when to do which kinds of updates
and notifiers. I can't specify totally exact how to make these
decisions, but these are basically the guidelines I use. So, new
and updated docs are here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/NotifiersUpdates
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataNotifiers
2009-09-04 22:51:09 +02:00
|
|
|
ED_region_tag_redraw(ar);
|
|
|
|
break;
|
2009-12-10 10:58:10 +01:00
|
|
|
case NC_ID:
|
2012-03-24 07:38:07 +01:00
|
|
|
if (wmn->action == NA_RENAME)
|
2009-12-14 00:51:41 +01:00
|
|
|
ED_region_tag_redraw(ar);
|
2009-12-10 10:58:10 +01:00
|
|
|
break;
|
2009-06-08 12:38:28 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* ************************************* */
|
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* only called once, from space/spacetypes.c */
|
|
|
|
void ED_spacetype_sequencer(void)
|
|
|
|
{
|
2012-03-30 00:26:11 +02:00
|
|
|
SpaceType *st = MEM_callocN(sizeof(SpaceType), "spacetype sequencer");
|
2008-12-14 15:43:08 +01:00
|
|
|
ARegionType *art;
|
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
st->spaceid = SPACE_SEQ;
|
2009-12-19 23:37:51 +01:00
|
|
|
strncpy(st->name, "Sequencer", BKE_ST_MAXNAME);
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
st->new = sequencer_new;
|
|
|
|
st->free = sequencer_free;
|
|
|
|
st->init = sequencer_init;
|
|
|
|
st->duplicate = sequencer_duplicate;
|
|
|
|
st->operatortypes = sequencer_operatortypes;
|
|
|
|
st->keymap = sequencer_keymap;
|
2012-06-07 21:24:49 +02:00
|
|
|
st->context = sequencer_context;
|
2012-03-30 00:26:11 +02:00
|
|
|
st->dropboxes = sequencer_dropboxes;
|
|
|
|
st->refresh = sequencer_refresh;
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 12:05:07 +02:00
|
|
|
st->listener = sequencer_listener;
|
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 19:18:21 +01:00
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* regions: main window */
|
2012-03-30 00:26:11 +02:00
|
|
|
art = MEM_callocN(sizeof(ARegionType), "spacetype sequencer region");
|
2008-12-14 15:43:08 +01:00
|
|
|
art->regionid = RGN_TYPE_WINDOW;
|
2012-03-30 00:26:11 +02:00
|
|
|
art->init = sequencer_main_area_init;
|
|
|
|
art->draw = sequencer_main_area_draw;
|
|
|
|
art->listener = sequencer_main_area_listener;
|
|
|
|
art->keymapflag = ED_KEYMAP_VIEW2D | ED_KEYMAP_MARKERS | ED_KEYMAP_FRAMES | ED_KEYMAP_ANIMATION;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
BLI_addhead(&st->regiontypes, art);
|
2009-12-14 22:42:25 +01:00
|
|
|
|
|
|
|
/* preview */
|
2012-03-30 00:26:11 +02:00
|
|
|
art = MEM_callocN(sizeof(ARegionType), "spacetype sequencer region");
|
2009-12-14 22:42:25 +01:00
|
|
|
art->regionid = RGN_TYPE_PREVIEW;
|
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 19:18:21 +01:00
|
|
|
art->prefsizey = 240; // XXX
|
2012-03-30 00:26:11 +02:00
|
|
|
art->init = sequencer_preview_area_init;
|
|
|
|
art->draw = sequencer_preview_area_draw;
|
|
|
|
art->listener = sequencer_preview_area_listener;
|
2012-06-11 02:21:50 +02:00
|
|
|
art->keymapflag = ED_KEYMAP_VIEW2D | ED_KEYMAP_FRAMES | ED_KEYMAP_GPENCIL;
|
2009-12-14 22:42:25 +01:00
|
|
|
BLI_addhead(&st->regiontypes, art);
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2009-06-08 12:38:28 +02:00
|
|
|
/* regions: listview/buttons */
|
2012-03-30 00:26:11 +02:00
|
|
|
art = MEM_callocN(sizeof(ARegionType), "spacetype sequencer region");
|
2009-06-08 12:38:28 +02:00
|
|
|
art->regionid = RGN_TYPE_UI;
|
2012-03-30 00:26:11 +02:00
|
|
|
art->prefsizex = 220; // XXX
|
|
|
|
art->keymapflag = ED_KEYMAP_UI | ED_KEYMAP_FRAMES;
|
|
|
|
art->listener = sequencer_buttons_area_listener;
|
|
|
|
art->init = sequencer_buttons_area_init;
|
|
|
|
art->draw = sequencer_buttons_area_draw;
|
2009-06-08 12:38:28 +02:00
|
|
|
BLI_addhead(&st->regiontypes, art);
|
2012-06-11 02:21:50 +02:00
|
|
|
|
|
|
|
sequencer_buttons_register(art);
|
2009-06-08 12:38:28 +02:00
|
|
|
|
2008-12-14 15:43:08 +01:00
|
|
|
/* regions: header */
|
2012-03-30 00:26:11 +02:00
|
|
|
art = MEM_callocN(sizeof(ARegionType), "spacetype sequencer region");
|
2008-12-14 15:43:08 +01:00
|
|
|
art->regionid = RGN_TYPE_HEADER;
|
2012-03-30 00:26:11 +02:00
|
|
|
art->prefsizey = HEADERY;
|
|
|
|
art->keymapflag = ED_KEYMAP_UI | ED_KEYMAP_VIEW2D | ED_KEYMAP_FRAMES | ED_KEYMAP_HEADER;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
2012-03-30 00:26:11 +02:00
|
|
|
art->init = sequencer_header_area_init;
|
|
|
|
art->draw = sequencer_header_area_draw;
|
|
|
|
art->listener = sequencer_main_area_listener;
|
2008-12-14 15:43:08 +01:00
|
|
|
|
|
|
|
BLI_addhead(&st->regiontypes, art);
|
|
|
|
|
|
|
|
BKE_spacetype_register(st);
|
2010-03-09 08:41:04 +01:00
|
|
|
|
|
|
|
/* set the sequencer callback when not in background mode */
|
2012-03-30 00:26:11 +02:00
|
|
|
if (G.background == 0) {
|
2012-03-07 20:19:56 +01:00
|
|
|
sequencer_view3d_cb = ED_view3d_draw_offscreen_imbuf_simple;
|
2010-03-09 08:41:04 +01:00
|
|
|
}
|
2008-12-14 15:43:08 +01:00
|
|
|
}
|