2011-02-17 05:57:18 +00:00
|
|
|
/*
|
2007-12-24 18:27:28 +00: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
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
2007-12-24 18:27:28 +00:00
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2007-12-24 18:27:28 +00:00
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2007 Blender Foundation.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2007-12-24 18:27:28 +00:00
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
|
*
|
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
|
*/
|
2012-02-17 18:59:41 +00:00
|
|
|
#ifndef __WM_API_H__
|
|
|
|
|
#define __WM_API_H__
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2016-02-21 01:24:17 +01:00
|
|
|
/** \file blender/windowmanager/WM_api.h
|
2011-02-17 05:57:18 +00:00
|
|
|
* \ingroup wm
|
|
|
|
|
*
|
2018-09-02 18:28:27 +10:00
|
|
|
* \page wmpage windowmanager
|
|
|
|
|
* \section wmabout About windowmanager
|
|
|
|
|
* \ref wm handles events received from \ref GHOST and manages
|
|
|
|
|
* the screens, areas and input for Blender
|
|
|
|
|
* \section wmnote NOTE
|
|
|
|
|
* \todo document
|
2011-02-17 05:57:18 +00:00
|
|
|
*/
|
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* dna-savable wmStructs here */
|
|
|
|
|
#include "DNA_windowmanager_types.h"
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
#include "WM_keymap.h"
|
2013-09-01 15:01:15 +00:00
|
|
|
#include "BLI_compiler_attrs.h"
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2010-10-05 00:05:14 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
struct bContext;
|
2018-05-16 18:41:11 +02:00
|
|
|
struct bToolRef_Runtime;
|
2014-10-28 15:41:05 +01:00
|
|
|
struct GHashIterator;
|
2008-12-16 20:03:28 +00:00
|
|
|
struct IDProperty;
|
2007-12-24 18:27:28 +00:00
|
|
|
struct wmEvent;
|
|
|
|
|
struct wmEventHandler;
|
2008-01-19 17:54:05 +00:00
|
|
|
struct wmGesture;
|
2.5
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
2009-01-22 14:59:49 +00:00
|
|
|
struct wmJob;
|
2018-05-08 07:25:36 +02:00
|
|
|
struct wmMsgSubscribeKey;
|
|
|
|
|
struct wmMsgSubscribeValue;
|
2009-12-24 16:10:26 +00:00
|
|
|
struct wmOperatorType;
|
|
|
|
|
struct wmOperator;
|
2008-11-18 13:51:02 +00:00
|
|
|
struct rcti;
|
2009-01-01 20:44:40 +00:00
|
|
|
struct PointerRNA;
|
2012-12-18 14:11:19 +00:00
|
|
|
struct PropertyRNA;
|
2009-10-08 19:06:32 +00:00
|
|
|
struct MenuType;
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
struct wmDropBox;
|
|
|
|
|
struct wmDrag;
|
|
|
|
|
struct ImBuf;
|
2012-12-23 13:57:09 +00:00
|
|
|
struct ImageFormatData;
|
2013-05-13 13:32:42 +00:00
|
|
|
struct ARegion;
|
2016-10-17 19:25:56 +02:00
|
|
|
struct ScrArea;
|
2017-07-26 18:00:26 +10:00
|
|
|
struct Main;
|
2018-04-05 18:20:27 +02:00
|
|
|
struct ViewLayer;
|
2018-04-27 10:22:37 +02:00
|
|
|
struct GPUViewport;
|
2018-02-08 21:14:26 +11:00
|
|
|
|
2016-08-18 00:21:55 -04:00
|
|
|
#ifdef WITH_INPUT_NDOF
|
2014-02-18 23:51:11 +11:00
|
|
|
struct wmNDOFMotionData;
|
2016-08-18 00:21:55 -04:00
|
|
|
#endif
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2.5
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
2009-01-22 14:59:49 +00:00
|
|
|
typedef struct wmJob wmJob;
|
2018-07-14 23:49:00 +02:00
|
|
|
typedef struct wmGizmo wmGizmo;
|
|
|
|
|
typedef struct wmGizmoMap wmGizmoMap;
|
|
|
|
|
typedef struct wmGizmoMapType wmGizmoMapType;
|
2.5
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
2009-01-22 14:59:49 +00:00
|
|
|
|
2009-01-02 14:11:18 +00:00
|
|
|
/* general API */
|
2018-08-17 16:34:51 +10:00
|
|
|
void WM_init_state_app_template_set(const char *app_template);
|
|
|
|
|
const char *WM_init_state_app_template_get(void);
|
|
|
|
|
|
2012-08-11 22:12:32 +00:00
|
|
|
void WM_init_state_size_set (int stax, int stay, int sizx, int sizy);
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_init_state_fullscreen_set(void);
|
|
|
|
|
void WM_init_state_normal_set(void);
|
2013-04-04 02:05:11 +00:00
|
|
|
void WM_init_native_pixels(bool do_it);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2011-02-19 12:05:20 +00:00
|
|
|
void WM_init (struct bContext *C, int argc, const char **argv);
|
2013-12-05 17:26:03 +11:00
|
|
|
void WM_exit_ext (struct bContext *C, const bool do_python);
|
2012-09-20 01:02:39 +00:00
|
|
|
|
2013-09-01 15:01:15 +00:00
|
|
|
void WM_exit (struct bContext *C) ATTR_NORETURN;
|
2012-09-20 01:02:39 +00:00
|
|
|
|
2013-09-01 15:01:15 +00:00
|
|
|
void WM_main (struct bContext *C) ATTR_NORETURN;
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2009-11-23 13:58:55 +00:00
|
|
|
void WM_init_splash (struct bContext *C);
|
|
|
|
|
|
2018-06-25 12:50:32 +02:00
|
|
|
void WM_init_opengl (struct Main *bmain);
|
2009-11-11 04:08:09 +00:00
|
|
|
|
|
|
|
|
void WM_check (struct bContext *C);
|
|
|
|
|
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
int WM_window_pixels_x(const struct wmWindow *win);
|
|
|
|
|
int WM_window_pixels_y(const struct wmWindow *win);
|
2018-05-23 22:38:25 +02:00
|
|
|
void WM_window_rect_calc(const struct wmWindow *win, struct rcti *r_rect);
|
|
|
|
|
void WM_window_screen_rect_calc(const struct wmWindow *win, struct rcti *r_rect);
|
UI: New Global Top-Bar (WIP)
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
2018-04-20 17:14:03 +02:00
|
|
|
bool WM_window_is_fullscreen(struct wmWindow *win);
|
Holiday coding log :)
Nice formatted version (pictures soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability
Short list of main changes:
- Transparent region option (over main region), added code to blend in/out such panels.
- Min size window now 640 x 480
- Fixed DPI for ui - lots of cleanup and changes everywhere. Icon image need correct size still, layer-in-use icon needs remake.
- Macbook retina support, use command line --no-native-pixels to disable it
- Timeline Marker label was drawing wrong
- Trackpad and magic mouse: supports zoom (hold ctrl)
- Fix for splash position: removed ghost function and made window size update after creation immediate
- Fast undo buffer save now adds UI as well. Could be checked for regular file save even...
Quit.blend and temp file saving use this now.
- Dixed filename in window on reading quit.blend or temp saves, and they now add a warning in window title: "(Recovered)"
- New Userpref option "Keep Session" - this always saves quit.blend, and loads on start.
This allows keeping UI and data without actual saves, until you actually save.
When you load startup.blend and quit, it recognises the quit.blend as a startup (no file name in header)
- Added 3D view copy/paste buffers (selected objects). Shortcuts ctrl-c, ctrl-v (OSX, cmd-c, cmd-v).
Coded partial file saving for it. Could be used for other purposes. Todo: use OS clipboards.
- User preferences (themes, keymaps, user settings) now can be saved as a separate file.
Old option is called "Save Startup File" the new one "Save User Settings".
To visualise this difference, the 'save startup file' button has been removed from user preferences window. That option is available as CTRL+U and in File menu still.
- OSX: fixed bug that stopped giving mouse events outside window.
This also fixes "Continuous Grab" for OSX. (error since 2009)
2012-12-12 18:58:11 +00:00
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
void WM_windows_scene_data_sync(const ListBase *win_lb, struct Scene *scene) ATTR_NONNULL();
|
|
|
|
|
struct Scene *WM_windows_scene_get_from_screen(const struct wmWindowManager *wm, const struct bScreen *screen) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
2017-10-16 17:15:03 -02:00
|
|
|
struct WorkSpace *WM_windows_workspace_get_from_screen(const wmWindowManager *wm, const struct bScreen *screen) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
|
|
|
|
|
struct Scene *WM_window_get_active_scene(const struct wmWindow *win) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
2018-07-03 15:34:26 +02:00
|
|
|
void WM_window_set_active_scene(struct Main *bmain, struct bContext *C, struct wmWindow *win,
|
2018-07-04 13:00:46 +02:00
|
|
|
struct Scene *scene_new) ATTR_NONNULL();
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
struct WorkSpace *WM_window_get_active_workspace(const struct wmWindow *win) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
2018-07-03 15:34:26 +02:00
|
|
|
void WM_window_set_active_workspace(struct bContext *C, struct wmWindow *win, struct WorkSpace *workspace) ATTR_NONNULL(1);
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
struct WorkSpaceLayout *WM_window_get_active_layout(const struct wmWindow *win) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
void WM_window_set_active_layout(
|
|
|
|
|
struct wmWindow *win, struct WorkSpace *workspace, struct WorkSpaceLayout *layout) ATTR_NONNULL(1);
|
|
|
|
|
struct bScreen *WM_window_get_active_screen(const struct wmWindow *win) ATTR_NONNULL() ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
void WM_window_set_active_screen(struct wmWindow *win, struct WorkSpace *workspace, struct bScreen *screen) ATTR_NONNULL(1);
|
2018-04-05 18:20:27 +02:00
|
|
|
|
|
|
|
|
struct ViewLayer *WM_window_get_active_view_layer(const struct wmWindow *win) ATTR_NONNULL(1) ATTR_WARN_UNUSED_RESULT;
|
2018-07-04 13:00:46 +02:00
|
|
|
void WM_window_set_active_view_layer(struct wmWindow *win, struct ViewLayer *view_layer) ATTR_NONNULL(1);
|
|
|
|
|
void WM_window_ensure_active_view_layer(struct wmWindow *win) ATTR_NONNULL(1);
|
2018-04-05 18:20:27 +02:00
|
|
|
|
Main Workspace Integration
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
2017-06-01 19:56:58 +02:00
|
|
|
bool WM_window_is_temp_screen(const struct wmWindow *win) ATTR_WARN_UNUSED_RESULT;
|
|
|
|
|
|
2018-02-26 19:41:17 +01:00
|
|
|
void *WM_opengl_context_create(void);
|
|
|
|
|
void WM_opengl_context_dispose(void *context);
|
|
|
|
|
void WM_opengl_context_activate(void *context);
|
|
|
|
|
void WM_opengl_context_release(void *context);
|
|
|
|
|
|
2013-05-28 01:15:59 +00:00
|
|
|
/* defines for 'type' WM_window_open_temp */
|
2015-10-07 00:27:27 +11:00
|
|
|
enum {
|
|
|
|
|
WM_WINDOW_RENDER = 1,
|
|
|
|
|
WM_WINDOW_USERPREFS,
|
2018-05-22 16:18:09 +02:00
|
|
|
WM_WINDOW_DRIVERS,
|
2015-10-07 00:27:27 +11:00
|
|
|
// WM_WINDOW_FILESEL // UNUSED
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct wmWindow *WM_window_open(struct bContext *C, const struct rcti *rect);
|
2017-04-20 00:17:42 +02:00
|
|
|
struct wmWindow *WM_window_open_temp(struct bContext *C, int x, int y, int sizex, int sizey, int type);
|
2017-07-08 00:44:31 +02:00
|
|
|
void WM_window_set_dpi(wmWindow *win);
|
2018-06-07 16:43:52 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
bool WM_stereo3d_enabled(struct wmWindow *win, bool only_fullscreen_test);
|
2009-07-24 12:43:59 +00:00
|
|
|
|
2008-11-18 13:51:02 +00:00
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* files */
|
2013-06-18 18:11:52 +00:00
|
|
|
void WM_file_autoexec_init(const char *filepath);
|
2014-01-29 05:33:05 +11:00
|
|
|
bool WM_file_read(struct bContext *C, const char *filepath, struct ReportList *reports);
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_autosave_init(struct wmWindowManager *wm);
|
2013-04-13 12:03:20 +00:00
|
|
|
void WM_recover_last_session(struct bContext *C, struct ReportList *reports);
|
2018-02-16 23:37:47 +11:00
|
|
|
void WM_file_tag_modified(void);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2016-07-19 17:49:01 +02:00
|
|
|
void WM_lib_reload(struct Library *lib, struct bContext *C, struct ReportList *reports);
|
|
|
|
|
|
2007-12-24 18:27:28 +00:00
|
|
|
/* mouse cursors */
|
2013-09-06 22:34:29 +00:00
|
|
|
void WM_cursor_set(struct wmWindow *win, int curs);
|
2018-05-18 11:44:28 +02:00
|
|
|
bool WM_cursor_set_from_tool(struct wmWindow *win, const ScrArea *sa, const ARegion *ar);
|
2013-09-06 22:34:29 +00:00
|
|
|
void WM_cursor_modal_set(struct wmWindow *win, int curs);
|
|
|
|
|
void WM_cursor_modal_restore(struct wmWindow *win);
|
2013-04-04 02:05:11 +00:00
|
|
|
void WM_cursor_wait (bool val);
|
2013-04-04 15:16:29 +00:00
|
|
|
void WM_cursor_grab_enable(struct wmWindow *win, bool wrap, bool hide, int bounds[4]);
|
2014-06-11 11:27:53 +10:00
|
|
|
void WM_cursor_grab_disable(struct wmWindow *win, const int mouse_ungrab_xy[2]);
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_cursor_time (struct wmWindow *win, int nr);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2018-07-02 11:47:00 +02:00
|
|
|
void *WM_paint_cursor_activate(
|
|
|
|
|
struct wmWindowManager *wm,
|
|
|
|
|
bool (*poll)(struct bContext *C),
|
|
|
|
|
void (*draw)(struct bContext *C, int, int, void *customdata),
|
|
|
|
|
void *customdata);
|
2012-02-29 15:00:37 +00:00
|
|
|
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
void WM_paint_cursor_end(struct wmWindowManager *wm, void *handle);
|
2013-05-13 13:32:42 +00:00
|
|
|
void WM_paint_cursor_tag_redraw(struct wmWindow *win, struct ARegion *ar);
|
2009-11-11 08:32:29 +00:00
|
|
|
|
|
|
|
|
void WM_cursor_warp (struct wmWindow *win, int x, int y);
|
2015-09-08 23:46:56 +10:00
|
|
|
void WM_cursor_compatible_xy(wmWindow *win, int *x, int *y);
|
2013-01-16 19:22:15 +00:00
|
|
|
float WM_cursor_pressure (const struct wmWindow *win);
|
2.5
Vertex Paint back!
Added WM level "paint cursor" system, which manages a custom painting
cursor for tools or modes.
- Activate it with WM_paint_cursor_activate(). That function wants two
callbacks, a poll(C) to check whether there's a cursor in given context
and ARegion, and a draw(C, x, y) which gets called when appropriate.
- While paintcursor is active, the WM handles necessary redrawing events
for all regions, also to nicely clear the cursor on region exit.
- WM_paint_cursor_activate returns a handle, which you have to use to
end the paint cursor. This handle also means you can register as many
custom cursors as you want.
At the moment, vertex paint mode registers only a mousemove handler,
all other events are still normally handled. This is stuff for the
future todo.
2009-01-09 13:55:45 +00:00
|
|
|
|
KEYMAP REFACTORING
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
2011-08-05 20:45:26 +00:00
|
|
|
/* event map */
|
Keymap conflict detection operator.
Takes into account the hierarchical structures of keymaps as well as wildcards (KM_ANY) in event definitions, user remaps (emulate numpad, action/select mouse buttons, ...) and event values that overlap (click, press and release)
For now, doesn't do anything other than print conflicts in the console.
As a result, I cleaned up a lot of keymaps that had double definitions, moved some keymap items in more appropriate places, fixed wrong definitions and removed kmi that were added for testing a long long time ago.
Out of all the remaining conflicts, after removing obvious non-issues, here's what remains: http://www.pasteall.org/9898
2009-12-17 22:14:43 +00:00
|
|
|
int WM_userdef_event_map(int kmitype);
|
2017-07-25 21:34:20 +10:00
|
|
|
int WM_userdef_event_type_from_keymap_type(int kmitype);
|
Key Configuration
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
2009-10-08 18:40:03 +00:00
|
|
|
|
2008-12-16 07:32:12 +00:00
|
|
|
/* handlers */
|
2008-12-08 15:02:57 +00:00
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
struct wmEventHandler *WM_event_add_keymap_handler(ListBase *handlers, wmKeyMap *keymap);
|
2008-12-10 13:56:54 +00:00
|
|
|
/* boundbox, optional subwindow boundbox for offset */
|
2014-01-19 23:14:24 +11:00
|
|
|
struct wmEventHandler *WM_event_add_keymap_handler_bb(ListBase *handlers, wmKeyMap *keymap, const rcti *bb, const rcti *swinbb);
|
2009-01-23 14:43:25 +00:00
|
|
|
/* priority not implemented, it adds in begin */
|
2009-09-17 21:36:02 +00:00
|
|
|
struct wmEventHandler *WM_event_add_keymap_handler_priority(ListBase *handlers, wmKeyMap *keymap, int priority);
|
2008-12-10 13:56:54 +00:00
|
|
|
|
2009-09-17 21:36:02 +00:00
|
|
|
void WM_event_remove_keymap_handler(ListBase *handlers, wmKeyMap *keymap);
|
Lots of stuff; couldn't commit in parts because of refactor work.
* Changes in interface/ module
This commit brings back the way how buttons/menus work under control
of WM event system. The previous implementation extended usage of
handlers and operators in an interesting but confusing way. Better to
try it first according the design specs. :)
Most obviously:
- modal-handler operators are not stored anymore in regions/areas/windows.
such modal handlers own their operator, and should remove it themselves.
- removed code to move handlers from one queue to another.
(needs review with brecht!)
- WM fix: the API call to remove a modal handler got removed. This was a
dangerous thing anyway, and you should leave that to the event system.
Now, if a handler modal() call gets a cancel/finish return, it frees
itself in event system. WM_event_remove_modal_handler was a confusing
call anyway!
Todo:
- allow button-activate to refresh after using button
- re-enable arrow keys for menus
(do both after commit)
- review return values of operator callbacks in interface_ops.c
* Fixes in WM system
- Freeing areas/regions/windows, also on quit, now correctly closes
running modal handlers
- On starting a modal handler, the handler now stores previous area
and region context, so they send proper notifiers etc.
* Other fixes
- Area-split operator had bug, wrong minimal size checking. This
solves error when trying to split a very narrow area.
- removed DNA_USHORT_FIX from screen_types.h, gave warning
- operators didn't get ID name copied when activated, needed for
later re-use or saving.
2008-12-02 14:22:52 +00:00
|
|
|
|
2018-05-20 22:34:18 +02:00
|
|
|
void WM_event_set_keymap_handler_callback(
|
|
|
|
|
struct wmEventHandler *handler,
|
|
|
|
|
void (keymap_tag)(wmKeyMap *keymap, wmKeyMapItem *kmi, void *user_data),
|
|
|
|
|
void *user_data);
|
|
|
|
|
|
2014-06-03 08:58:16 +10:00
|
|
|
typedef int (*wmUIHandlerFunc)(struct bContext *C, const struct wmEvent *event, void *userdata);
|
|
|
|
|
typedef void (*wmUIHandlerRemoveFunc)(struct bContext *C, void *userdata);
|
|
|
|
|
|
2012-12-20 00:29:31 +00:00
|
|
|
struct wmEventHandler *WM_event_add_ui_handler(
|
2013-09-04 03:30:41 +00:00
|
|
|
const struct bContext *C, ListBase *handlers,
|
2014-06-03 08:58:16 +10:00
|
|
|
wmUIHandlerFunc ui_handle, wmUIHandlerRemoveFunc ui_remove,
|
2015-06-01 16:40:43 +10:00
|
|
|
void *userdata, const char flag);
|
2014-06-03 08:58:16 +10:00
|
|
|
void WM_event_remove_ui_handler(
|
|
|
|
|
ListBase *handlers,
|
|
|
|
|
wmUIHandlerFunc ui_handle, wmUIHandlerRemoveFunc ui_remove,
|
|
|
|
|
void *userdata, const bool postpone);
|
|
|
|
|
void WM_event_remove_area_handler(
|
|
|
|
|
struct ListBase *handlers, void *area);
|
|
|
|
|
void WM_event_free_ui_handler_all(
|
|
|
|
|
struct bContext *C, ListBase *handlers,
|
|
|
|
|
wmUIHandlerFunc ui_handle, wmUIHandlerRemoveFunc ui_remove);
|
UI: don't use operators anymore for handling user interface events, but rather
a special UI handler which makes the code clearer. This UI handler is attached
to the region along with other handlers, and also gets a callback when all
handlers for the region are removed to ensure things are properly cleaned up.
This should fix XXX's in the UI code related to events and context switching.
Most of the changes are in interface_handlers.c, which was renamed from
interface_ops.c, to convert operators to the UI handler. UI code notes:
* uiBeginBlock/uiEndBlock/uiFreeBlocks now takes a context argument, this is
required to properly cancel things like timers or tooltips when the region
gets removed.
* UI_add_region_handlers will add the region level UI handlers, to be used
when adding keymap handlers etc. This replaces the UI keymap.
* When the UI code starts a modal interaction (number sliding, text editing,
opening a menu, ..), it will add an UI handler at the window level which
will block events.
Windowmanager changes:
* Added an UI handler next to the existing keymap and operator modal handlers.
It has an event handling and remove callback, and like operator modal handlers
will remember the area and region if it is registered at the window level.
* Removed the MESSAGE event.
* Operator cancel and UI handler remove callbacks now get the
window/area/region restored in the context, like the operator modal and UI
handler event callbacks.
* Regions now receive MOUSEMOVE events for the mouse going outside of the
region. This was already happening for areas, but UI buttons are at the region
level so we need it there.
Issues:
* Tooltips and menus stay open when switching to another window, and button
highlight doesn't work without moving the mouse first when Blender starts up.
I tried using some events like Q_FIRSTTIME, WINTHAW, but those don't seem to
arrive..
* Timeline header buttons seem to be moving one pixel or so sometimes when
interacting with them.
* Seems not due to this commit, but UI and keymap handlers are leaking. It
seems that handlers are being added to regions in all screens, also in regions
of areas that are not visible, but these handlers are not removed. Probably
there should only be handlers in visible regions?
2008-12-10 04:36:33 +00:00
|
|
|
|
2009-09-18 12:43:36 +00:00
|
|
|
struct wmEventHandler *WM_event_add_modal_handler(struct bContext *C, struct wmOperator *op);
|
2016-10-17 19:25:56 +02:00
|
|
|
void WM_event_modal_handler_area_replace(wmWindow *win, const struct ScrArea *old_area, struct ScrArea *new_area);
|
|
|
|
|
void WM_event_modal_handler_region_replace(wmWindow *win, const struct ARegion *old_region, struct ARegion *new_region);
|
|
|
|
|
|
2008-12-19 14:14:43 +00:00
|
|
|
void WM_event_remove_handlers(struct bContext *C, ListBase *handlers);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2015-06-01 16:40:43 +10:00
|
|
|
/* handler flag */
|
|
|
|
|
enum {
|
|
|
|
|
WM_HANDLER_BLOCKING = (1 << 0), /* after this handler all others are ignored */
|
|
|
|
|
WM_HANDLER_ACCEPT_DBL_CLICK = (1 << 1), /* handler accepts double key press events */
|
|
|
|
|
|
|
|
|
|
/* internal */
|
|
|
|
|
WM_HANDLER_DO_FREE = (1 << 7), /* handler tagged to be freed in wm_handlers_do() */
|
|
|
|
|
};
|
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
struct wmEventHandler *WM_event_add_dropbox_handler(ListBase *handlers, ListBase *dropboxes);
|
|
|
|
|
|
|
|
|
|
/* mouse */
|
2018-03-22 23:52:38 +01:00
|
|
|
void WM_event_add_mousemove(const struct bContext *C);
|
2017-07-18 18:09:26 +10:00
|
|
|
bool WM_event_is_modal_tweak_exit(const struct wmEvent *event, int tweak_event);
|
2017-07-18 18:06:21 +10:00
|
|
|
bool WM_event_is_last_mousemove(const struct wmEvent *event);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2016-08-18 00:21:55 -04:00
|
|
|
#ifdef WITH_INPUT_NDOF
|
2015-07-01 13:45:19 +10:00
|
|
|
/* 3D mouse */
|
|
|
|
|
void WM_ndof_deadzone_set(float deadzone);
|
2016-08-18 00:21:55 -04:00
|
|
|
#endif
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* notifiers */
|
2009-10-07 21:39:24 +00:00
|
|
|
void WM_event_add_notifier(const struct bContext *C, unsigned int type, void *reference);
|
|
|
|
|
void WM_main_add_notifier(unsigned int type, void *reference);
|
2013-04-08 13:03:04 +00:00
|
|
|
void WM_main_remove_notifier_reference(const void *reference);
|
ID-Remap - Step one: core work (cleanup and rework of generic ID datablock handling).
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
2016-06-22 17:29:38 +02:00
|
|
|
void WM_main_remap_editor_id_reference(struct ID *old_id, struct ID *new_id);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2013-07-03 20:37:07 +00:00
|
|
|
/* reports */
|
2016-01-16 21:51:05 +01:00
|
|
|
void WM_report_banner_show(void);
|
|
|
|
|
void WM_report(ReportType type, const char *message);
|
|
|
|
|
void WM_reportf(ReportType type, const char *format, ...) ATTR_PRINTF_FORMAT(2, 3);
|
2013-07-03 20:37:07 +00:00
|
|
|
|
2018-01-10 12:25:20 +11:00
|
|
|
struct wmEvent *wm_event_add_ex(
|
2015-05-26 19:57:52 +10:00
|
|
|
struct wmWindow *win, const struct wmEvent *event_to_add,
|
|
|
|
|
const struct wmEvent *event_to_add_after)
|
|
|
|
|
ATTR_NONNULL(1, 2);
|
2018-01-10 12:25:20 +11:00
|
|
|
struct wmEvent *wm_event_add(
|
2015-05-26 19:57:52 +10:00
|
|
|
struct wmWindow *win, const struct wmEvent *event_to_add)
|
|
|
|
|
ATTR_NONNULL(1, 2);
|
|
|
|
|
|
|
|
|
|
void wm_event_init_from_window(struct wmWindow *win, struct wmEvent *event);
|
2013-07-29 08:29:04 +00:00
|
|
|
|
2.5 getting-back-into-coding commit :)
- cleaned up join and split operations. Most noticable is operator callback
design, which should make a design based on user-less exec() first, then
wrap invoke() and modal() around it. The exec() should be callable with
only Context and properties.
- split now works again; and inversed as previously, if you drag from a
triangle (action zone) inside area it subdivides area as expected.
- dragging from triangle outside area, over an edge, joins areas
- split has been simplified, it had too many options... it could just work
simpler (now)
- 'action zone' now is an operator itself, a widget sending an ACTIONZONE event,
which can be handled by others (so other gestures can be added in action zone
too)
Still evaluating:
- context gets set where?
- code structure confuses... what are proper functions for operators?
- what is WM... should low level screen stuff more there?
- when do you send event, notifier?
- files grow to large, will clean
Oh yeah and docs, docs, docs. Coming! :)
2008-11-17 18:54:03 +00:00
|
|
|
|
2008-12-26 13:29:47 +00:00
|
|
|
/* at maximum, every timestep seconds it triggers event_type events */
|
2009-10-20 13:58:53 +00:00
|
|
|
struct wmTimer *WM_event_add_timer(struct wmWindowManager *wm, struct wmWindow *win, int event_type, double timestep);
|
2015-08-11 12:11:48 +02:00
|
|
|
struct wmTimer *WM_event_add_timer_notifier(struct wmWindowManager *wm, struct wmWindow *win, unsigned int type, double timestep);
|
2009-10-20 13:58:53 +00:00
|
|
|
void WM_event_remove_timer(struct wmWindowManager *wm, struct wmWindow *win, struct wmTimer *timer);
|
2015-08-11 12:11:48 +02:00
|
|
|
void WM_event_remove_timer_notifier(struct wmWindowManager *wm, struct wmWindow *win, struct wmTimer *timer);
|
2013-12-05 17:26:03 +11:00
|
|
|
void WM_event_timer_sleep(struct wmWindowManager *wm, struct wmWindow *win, struct wmTimer *timer, bool do_sleep);
|
2008-01-07 18:03:41 +00:00
|
|
|
|
2008-12-24 18:06:51 +00:00
|
|
|
/* operator api, default callbacks */
|
|
|
|
|
/* invoke callback, uses enum property named "type" */
|
2013-09-16 04:19:48 +00:00
|
|
|
void WM_operator_view3d_unit_defaults(struct bContext *C, struct wmOperator *op);
|
2013-09-16 04:04:44 +00:00
|
|
|
int WM_operator_smooth_viewtx_get(const struct wmOperator *op);
|
2016-05-31 16:30:44 +10:00
|
|
|
int WM_menu_invoke_ex(struct bContext *C, struct wmOperator *op, int opcontext);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_menu_invoke (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2018-01-03 10:16:26 -02:00
|
|
|
void WM_menu_name_call(struct bContext *C, const char *menu_name, short context);
|
2017-03-13 10:43:49 +01:00
|
|
|
int WM_enum_search_invoke_previews(struct bContext *C, struct wmOperator *op, short prv_cols, short prv_rows);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_enum_search_invoke(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2008-12-24 18:06:51 +00:00
|
|
|
/* invoke callback, confirm menu + exec */
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_operator_confirm (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2010-06-14 03:52:10 +00:00
|
|
|
/* invoke callback, file selector "filepath" unset + exec */
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_operator_filesel (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-06-18 15:30:51 +00:00
|
|
|
bool WM_operator_filesel_ensure_ext_imtype(wmOperator *op, const struct ImageFormatData *im_format);
|
2008-12-24 18:06:51 +00:00
|
|
|
/* poll callback, context checks */
|
2018-07-02 11:47:00 +02:00
|
|
|
bool WM_operator_winactive (struct bContext *C);
|
2009-04-01 14:02:06 +00:00
|
|
|
/* invoke callback, exec + redo popup */
|
2013-10-09 14:35:25 +00:00
|
|
|
int WM_operator_props_popup_confirm(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_operator_props_popup_call(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_operator_props_popup (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-03-26 07:29:01 +00:00
|
|
|
int WM_operator_props_dialog_popup(struct bContext *C, struct wmOperator *op, int width, int height);
|
2009-04-01 14:02:06 +00:00
|
|
|
int WM_operator_redo_popup (struct bContext *C, struct wmOperator *op);
|
2010-03-20 18:03:59 +00:00
|
|
|
int WM_operator_ui_popup (struct bContext *C, struct wmOperator *op, int width, int height);
|
2007-12-24 18:27:28 +00:00
|
|
|
|
2014-02-09 12:28:14 +11:00
|
|
|
int WM_operator_confirm_message_ex(struct bContext *C, struct wmOperator *op,
|
|
|
|
|
const char *title, const int icon,
|
|
|
|
|
const char *message);
|
|
|
|
|
int WM_operator_confirm_message(struct bContext *C, struct wmOperator *op,
|
|
|
|
|
const char *message);
|
2009-10-10 12:29:11 +00:00
|
|
|
|
2008-12-24 18:06:51 +00:00
|
|
|
/* operator api */
|
2008-12-24 14:52:17 +00:00
|
|
|
void WM_operator_free (struct wmOperator *op);
|
2017-03-15 05:16:07 +11:00
|
|
|
void WM_operator_free_all_after(wmWindowManager *wm, struct wmOperator *op);
|
2013-04-30 03:44:03 +00:00
|
|
|
void WM_operator_type_set(struct wmOperator *op, struct wmOperatorType *ot);
|
2011-05-18 10:56:26 +00:00
|
|
|
void WM_operator_stack_clear(struct wmWindowManager *wm);
|
2013-01-22 06:16:49 +00:00
|
|
|
void WM_operator_handlers_clear(wmWindowManager *wm, struct wmOperatorType *ot);
|
2009-06-26 15:48:09 +00:00
|
|
|
|
2018-07-02 11:47:00 +02:00
|
|
|
bool WM_operator_poll (struct bContext *C, struct wmOperatorType *ot);
|
|
|
|
|
bool WM_operator_poll_context(struct bContext *C, struct wmOperatorType *ot, short context);
|
2014-01-29 02:52:06 +11:00
|
|
|
int WM_operator_call_ex(struct bContext *C, struct wmOperator *op, const bool store);
|
2008-12-24 14:52:17 +00:00
|
|
|
int WM_operator_call (struct bContext *C, struct wmOperator *op);
|
2011-12-12 18:52:18 +00:00
|
|
|
int WM_operator_call_notest(struct bContext *C, struct wmOperator *op);
|
2009-02-01 12:00:00 +00:00
|
|
|
int WM_operator_repeat (struct bContext *C, struct wmOperator *op);
|
2014-02-03 18:55:59 +11:00
|
|
|
bool WM_operator_repeat_check(const struct bContext *C, struct wmOperator *op);
|
2017-03-15 03:43:44 +11:00
|
|
|
bool WM_operator_is_repeat(const struct bContext *C, const struct wmOperator *op);
|
2014-07-11 15:07:55 +10:00
|
|
|
int WM_operator_name_call_ptr(struct bContext *C, struct wmOperatorType *ot, short context, struct PointerRNA *properties);
|
|
|
|
|
int WM_operator_name_call(struct bContext *C, const char *opstring, short context, struct PointerRNA *properties);
|
2014-01-28 03:52:21 +11:00
|
|
|
int WM_operator_call_py(struct bContext *C, struct wmOperatorType *ot, short context, struct PointerRNA *properties, struct ReportList *reports, const bool is_undo);
|
2009-01-01 20:44:40 +00:00
|
|
|
|
2009-10-12 12:54:08 +00:00
|
|
|
void WM_operator_properties_alloc(struct PointerRNA **ptr, struct IDProperty **properties, const char *opstring); /* used for keymap and macro items */
|
2013-04-04 02:05:11 +00:00
|
|
|
void WM_operator_properties_sanitize(struct PointerRNA *ptr, const bool no_context); /* make props context sensitive or not */
|
2013-11-26 06:39:14 +11:00
|
|
|
bool WM_operator_properties_default(struct PointerRNA *ptr, const bool do_update);
|
2012-01-11 19:33:14 +00:00
|
|
|
void WM_operator_properties_reset(struct wmOperator *op);
|
2009-01-01 20:44:40 +00:00
|
|
|
void WM_operator_properties_create(struct PointerRNA *ptr, const char *opstring);
|
2009-11-24 16:19:15 +00:00
|
|
|
void WM_operator_properties_create_ptr(struct PointerRNA *ptr, struct wmOperatorType *ot);
|
2013-11-29 16:01:03 +11:00
|
|
|
void WM_operator_properties_clear(struct PointerRNA *ptr);
|
2009-01-01 20:44:40 +00:00
|
|
|
void WM_operator_properties_free(struct PointerRNA *ptr);
|
2009-11-29 22:16:29 +00:00
|
|
|
|
2018-05-02 10:24:14 +02:00
|
|
|
bool WM_operator_check_ui_empty(struct wmOperatorType *ot);
|
2013-04-04 02:05:11 +00:00
|
|
|
bool WM_operator_check_ui_enabled(const struct bContext *C, const char *idname);
|
2018-05-02 17:59:43 +02:00
|
|
|
|
|
|
|
|
IDProperty *WM_operator_last_properties_ensure_idprops(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operator_last_properties_ensure(struct wmOperatorType *ot, struct PointerRNA *ptr);
|
2011-05-23 10:14:07 +00:00
|
|
|
wmOperator *WM_operator_last_redo(const struct bContext *C);
|
2014-11-23 22:48:48 +01:00
|
|
|
ID *WM_operator_drop_load_path(struct bContext *C, struct wmOperator *op, const short idcode);
|
2011-05-23 10:14:07 +00:00
|
|
|
|
2013-04-04 02:05:11 +00:00
|
|
|
bool WM_operator_last_properties_init(struct wmOperator *op);
|
|
|
|
|
bool WM_operator_last_properties_store(struct wmOperator *op);
|
2012-03-21 06:33:31 +00:00
|
|
|
|
2015-12-27 16:36:08 +11:00
|
|
|
|
|
|
|
|
/* wm_operator_props.c */
|
2016-02-07 22:56:20 +11:00
|
|
|
void WM_operator_properties_filesel(
|
|
|
|
|
struct wmOperatorType *ot, int filter, short type, short action,
|
|
|
|
|
short flag, short display, short sort);
|
2015-12-27 16:36:08 +11:00
|
|
|
void WM_operator_properties_border(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operator_properties_border_to_rcti(struct wmOperator *op, struct rcti *rect);
|
|
|
|
|
void WM_operator_properties_border_to_rctf(struct wmOperator *op, rctf *rect);
|
2017-10-16 21:58:51 +11:00
|
|
|
void WM_operator_properties_gesture_border_ex(struct wmOperatorType *ot, bool deselect, bool extend);
|
|
|
|
|
void WM_operator_properties_gesture_border(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operator_properties_gesture_border_select(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operator_properties_gesture_border_zoom(struct wmOperatorType *ot);
|
2017-10-16 16:11:04 +11:00
|
|
|
void WM_operator_properties_gesture_lasso_ex(struct wmOperatorType *ot, bool deselect, bool extend);
|
|
|
|
|
void WM_operator_properties_gesture_lasso(struct wmOperatorType *ot);
|
2017-10-16 21:58:51 +11:00
|
|
|
void WM_operator_properties_gesture_lasso_select(struct wmOperatorType *ot);
|
2015-12-27 16:36:08 +11:00
|
|
|
void WM_operator_properties_gesture_straightline(struct wmOperatorType *ot, int cursor);
|
2017-10-16 21:58:51 +11:00
|
|
|
void WM_operator_properties_gesture_circle_ex(struct wmOperatorType *ot, bool deselect);
|
2017-10-16 15:32:09 +11:00
|
|
|
void WM_operator_properties_gesture_circle(struct wmOperatorType *ot);
|
2017-10-16 21:58:51 +11:00
|
|
|
void WM_operator_properties_gesture_circle_select(struct wmOperatorType *ot);
|
2017-10-16 15:32:09 +11:00
|
|
|
void WM_operator_properties_mouse_select(struct wmOperatorType *ot);
|
2015-12-27 16:36:08 +11:00
|
|
|
void WM_operator_properties_select_all(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operator_properties_select_action(struct wmOperatorType *ot, int default_action);
|
|
|
|
|
void WM_operator_properties_select_action_simple(struct wmOperatorType *ot, int default_action);
|
|
|
|
|
void WM_operator_properties_select_random(struct wmOperatorType *ot);
|
2016-03-29 01:20:45 +11:00
|
|
|
int WM_operator_properties_select_random_seed_increment_get(wmOperator *op);
|
2018-08-14 10:28:41 +10:00
|
|
|
void WM_operator_properties_select_operation(struct wmOperatorType *ot);
|
2015-12-27 17:46:55 +11:00
|
|
|
struct CheckerIntervalParams {
|
|
|
|
|
int nth; /* bypass when set to zero */
|
|
|
|
|
int skip;
|
|
|
|
|
int offset;
|
|
|
|
|
};
|
|
|
|
|
void WM_operator_properties_checker_interval(struct wmOperatorType *ot, bool nth_can_disable);
|
|
|
|
|
void WM_operator_properties_checker_interval_from_op(
|
|
|
|
|
struct wmOperator *op, struct CheckerIntervalParams *op_params);
|
|
|
|
|
bool WM_operator_properties_checker_interval_test(
|
|
|
|
|
const struct CheckerIntervalParams *op_params, int depth);
|
2015-12-27 16:36:08 +11:00
|
|
|
|
2010-07-01 19:28:45 +00:00
|
|
|
/* flags for WM_operator_properties_filesel */
|
|
|
|
|
#define WM_FILESEL_RELPATH (1 << 0)
|
|
|
|
|
|
|
|
|
|
#define WM_FILESEL_DIRECTORY (1 << 1)
|
|
|
|
|
#define WM_FILESEL_FILENAME (1 << 2)
|
|
|
|
|
#define WM_FILESEL_FILEPATH (1 << 3)
|
2011-08-12 03:53:26 +00:00
|
|
|
#define WM_FILESEL_FILES (1 << 4)
|
2010-07-01 19:28:45 +00:00
|
|
|
|
2012-03-09 00:41:09 +00:00
|
|
|
/* operator as a python command (resultuing string must be freed) */
|
2013-11-26 08:59:14 +11:00
|
|
|
char *WM_operator_pystring_ex(struct bContext *C, struct wmOperator *op,
|
|
|
|
|
const bool all_args, const bool macro_args,
|
2013-11-06 20:56:18 +00:00
|
|
|
struct wmOperatorType *ot, struct PointerRNA *opptr);
|
2013-11-26 08:59:14 +11:00
|
|
|
char *WM_operator_pystring(struct bContext *C, struct wmOperator *op,
|
|
|
|
|
const bool all_args, const bool macro_args);
|
2013-12-09 14:20:53 +11:00
|
|
|
bool WM_operator_pystring_abbreviate(char *str, int str_len_max);
|
2012-12-18 14:11:19 +00:00
|
|
|
char *WM_prop_pystring_assign(struct bContext *C, struct PointerRNA *ptr, struct PropertyRNA *prop, int index);
|
2009-07-18 19:42:13 +00:00
|
|
|
void WM_operator_bl_idname(char *to, const char *from);
|
|
|
|
|
void WM_operator_py_idname(char *to, const char *from);
|
2017-08-23 18:17:42 +10:00
|
|
|
bool WM_operator_py_idname_ok_or_report(struct ReportList *reports, const char *classname, const char *idname);
|
2018-06-30 20:59:10 +02:00
|
|
|
const char *WM_context_member_from_ptr(struct bContext *C, const struct PointerRNA *ptr);
|
2008-12-26 03:56:52 +00:00
|
|
|
|
2018-07-13 12:46:10 +02:00
|
|
|
/* wm_operator_type.c */
|
|
|
|
|
struct wmOperatorType *WM_operatortype_find(const char *idname, bool quiet);
|
|
|
|
|
void WM_operatortype_iter(struct GHashIterator *ghi);
|
|
|
|
|
void WM_operatortype_append(void (*opfunc)(struct wmOperatorType *));
|
|
|
|
|
void WM_operatortype_append_ptr(void (*opfunc)(struct wmOperatorType *, void *), void *userdata);
|
|
|
|
|
void WM_operatortype_append_macro_ptr(void (*opfunc)(struct wmOperatorType *, void *), void *userdata);
|
|
|
|
|
void WM_operatortype_remove_ptr(struct wmOperatorType *ot);
|
|
|
|
|
bool WM_operatortype_remove(const char *idname);
|
|
|
|
|
void WM_operatortype_last_properties_clear_all(void);
|
2018-07-13 12:52:10 +02:00
|
|
|
void WM_operatortype_props_advanced_begin(struct wmOperatorType *ot);
|
|
|
|
|
void WM_operatortype_props_advanced_end(struct wmOperatorType *ot);
|
|
|
|
|
|
|
|
|
|
#define WM_operatortype_prop_tag(property, tags) \
|
|
|
|
|
{ \
|
|
|
|
|
CHECK_TYPE(tags, eOperatorPropTags); \
|
|
|
|
|
RNA_def_property_tags(prop, tags); \
|
|
|
|
|
} (void)0
|
2018-07-13 12:46:10 +02:00
|
|
|
|
|
|
|
|
struct wmOperatorType *WM_operatortype_append_macro(const char *idname, const char *name, const char *description, int flag);
|
|
|
|
|
struct wmOperatorTypeMacro *WM_operatortype_macro_define(struct wmOperatorType *ot, const char *idname);
|
|
|
|
|
|
|
|
|
|
/* wm_uilist_type.c */
|
This commit frees list ui items from their dependencies to Panel, and hence from all the limitations this implied (mostly, the "only one list per panel" one).
It introduces a new (py-extendable and registrable) RNA type, UIList (roughly similar to Panel one), which currently contains only "standard" list's scroll pos and size (but may be expended to include e.g. some filtering data, etc.). This now makes lists completely independent from Panels!
This UIList has a draw_item callback which allows to customize items' drawing from python, that all addons can now use. Incidentally, this also greatly simplifies the C code of this widget, as we do not code any "special case" here anymore!
To make all this work, other changes were also necessary:
* Now all buttons (uiBut struct) have a 'custom_data' void pointer, used currently to store the uiList struct associated with a given uiLayoutListBox.
* DynamicPaintSurface now exposes a new bool, use_color_preview (readonly), saying whether that surface has some 3D view preview data or not.
* UILayout class has now four new (static) functions, to get the actual icon of any RNA object (important e.g. with materials or textures), and to get an enum item's UI name, description and icon.
* UILayout's label() func now takes an optional 'icon_value' integer parameter, which if not zero will override the 'icon' one (mandatory to use "custom" icons as generated for material/texture/... previews).
Note: not sure whether we should add that one to all UILayout's prop funcs?
Note: will update addons using template list asap.
2012-12-28 09:20:16 +00:00
|
|
|
void WM_uilisttype_init(void);
|
2013-04-04 02:05:11 +00:00
|
|
|
struct uiListType *WM_uilisttype_find(const char *idname, bool quiet);
|
2014-01-28 03:52:21 +11:00
|
|
|
bool WM_uilisttype_add(struct uiListType *ult);
|
This commit frees list ui items from their dependencies to Panel, and hence from all the limitations this implied (mostly, the "only one list per panel" one).
It introduces a new (py-extendable and registrable) RNA type, UIList (roughly similar to Panel one), which currently contains only "standard" list's scroll pos and size (but may be expended to include e.g. some filtering data, etc.). This now makes lists completely independent from Panels!
This UIList has a draw_item callback which allows to customize items' drawing from python, that all addons can now use. Incidentally, this also greatly simplifies the C code of this widget, as we do not code any "special case" here anymore!
To make all this work, other changes were also necessary:
* Now all buttons (uiBut struct) have a 'custom_data' void pointer, used currently to store the uiList struct associated with a given uiLayoutListBox.
* DynamicPaintSurface now exposes a new bool, use_color_preview (readonly), saying whether that surface has some 3D view preview data or not.
* UILayout class has now four new (static) functions, to get the actual icon of any RNA object (important e.g. with materials or textures), and to get an enum item's UI name, description and icon.
* UILayout's label() func now takes an optional 'icon_value' integer parameter, which if not zero will override the 'icon' one (mandatory to use "custom" icons as generated for material/texture/... previews).
Note: not sure whether we should add that one to all UILayout's prop funcs?
Note: will update addons using template list asap.
2012-12-28 09:20:16 +00:00
|
|
|
void WM_uilisttype_freelink(struct uiListType *ult);
|
|
|
|
|
void WM_uilisttype_free(void);
|
|
|
|
|
|
2018-07-13 12:46:10 +02:00
|
|
|
/* wm_menu_type.c */
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_menutype_init(void);
|
2013-04-04 02:05:11 +00:00
|
|
|
struct MenuType *WM_menutype_find(const char *idname, bool quiet);
|
2014-01-28 03:52:21 +11:00
|
|
|
bool WM_menutype_add(struct MenuType *mt);
|
2012-08-26 11:35:43 +00:00
|
|
|
void WM_menutype_freelink(struct MenuType *mt);
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_menutype_free(void);
|
2018-02-23 17:01:22 +11:00
|
|
|
bool WM_menutype_poll(struct bContext *C, struct MenuType *mt);
|
2009-10-08 19:06:32 +00:00
|
|
|
|
2018-07-13 18:39:46 +02:00
|
|
|
/* wm_panel_type.c */
|
|
|
|
|
void WM_paneltype_init(void);
|
|
|
|
|
void WM_paneltype_clear(void);
|
|
|
|
|
struct PanelType *WM_paneltype_find(const char *idname, bool quiet);
|
|
|
|
|
bool WM_paneltype_add(struct PanelType *mt);
|
|
|
|
|
void WM_paneltype_remove(struct PanelType *mt);
|
|
|
|
|
|
2017-10-17 15:09:29 +11:00
|
|
|
/* wm_gesture_ops.c */
|
2017-10-16 17:01:28 +11:00
|
|
|
int WM_gesture_border_invoke (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_gesture_border_modal (struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
void WM_gesture_border_cancel(struct bContext *C, struct wmOperator *op);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_gesture_circle_invoke(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_gesture_circle_modal(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-10-30 23:08:53 +00:00
|
|
|
void WM_gesture_circle_cancel(struct bContext *C, struct wmOperator *op);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_gesture_lines_invoke(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_gesture_lines_modal(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-10-30 23:08:53 +00:00
|
|
|
void WM_gesture_lines_cancel(struct bContext *C, struct wmOperator *op);
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_gesture_lasso_invoke(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_gesture_lasso_modal(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-10-30 23:08:53 +00:00
|
|
|
void WM_gesture_lasso_cancel(struct bContext *C, struct wmOperator *op);
|
2012-10-05 15:44:11 +00:00
|
|
|
const int (*WM_gesture_lasso_path_to_array(struct bContext *C, struct wmOperator *op, int *mcords_tot))[2];
|
2013-03-13 09:03:46 +00:00
|
|
|
int WM_gesture_straightline_invoke(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
|
|
|
|
int WM_gesture_straightline_modal(struct bContext *C, struct wmOperator *op, const struct wmEvent *event);
|
2013-10-30 23:08:53 +00:00
|
|
|
void WM_gesture_straightline_cancel(struct bContext *C, struct wmOperator *op);
|
Various changes made in the process of working on the UI code:
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
2008-11-11 15:18:21 +00:00
|
|
|
|
2008-01-19 17:54:05 +00:00
|
|
|
/* Gesture manager API */
|
2013-03-13 09:03:46 +00:00
|
|
|
struct wmGesture *WM_gesture_new(struct bContext *C, const struct wmEvent *event, int type);
|
2.5: gesture code in WM
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
2008-11-19 13:16:05 +00:00
|
|
|
void WM_gesture_end(struct bContext *C, struct wmGesture *gesture);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
void WM_gestures_remove(struct bContext *C);
|
2008-01-19 17:54:05 +00:00
|
|
|
|
2009-02-16 12:14:04 +00:00
|
|
|
/* fileselecting support */
|
|
|
|
|
void WM_event_add_fileselect(struct bContext *C, struct wmOperator *op);
|
2013-03-15 19:56:29 +00:00
|
|
|
void WM_event_fileselect_event(struct wmWindowManager *wm, void *ophandle, int eventval);
|
2013-03-03 03:29:57 +00:00
|
|
|
void WM_event_print(const struct wmEvent *event);
|
2009-02-16 12:14:04 +00:00
|
|
|
|
2013-01-30 12:22:02 +00:00
|
|
|
void WM_operator_region_active_win_set(struct bContext *C);
|
|
|
|
|
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
/* drag and drop */
|
2014-07-21 12:02:05 +02:00
|
|
|
struct wmDrag *WM_event_start_drag(struct bContext *C, int icon, int type, void *poin, double value, unsigned int flags);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
void WM_event_drag_image(struct wmDrag *, struct ImBuf *, float scale, int sx, int sy);
|
2014-07-21 12:02:05 +02:00
|
|
|
void WM_drag_free(struct wmDrag *drag);
|
|
|
|
|
void WM_drag_free_list(struct ListBase *lb);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2018-07-02 11:47:00 +02:00
|
|
|
struct wmDropBox *WM_dropbox_add(
|
2018-08-07 10:38:20 +02:00
|
|
|
ListBase *lb, const char *idname,
|
|
|
|
|
bool (*poll)(struct bContext *, struct wmDrag *, const struct wmEvent *event, const char **),
|
2018-07-02 11:47:00 +02:00
|
|
|
void (*copy)(struct wmDrag *, struct wmDropBox *));
|
2010-12-03 17:05:21 +00:00
|
|
|
ListBase *WM_dropboxmap_find(const char *idname, int spaceid, int regionid);
|
Drag and drop 2.5 integration! Finally, slashdot regulars can use
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 18:18:21 +00:00
|
|
|
|
2018-08-05 12:14:55 +02:00
|
|
|
/* ID drag and drop */
|
|
|
|
|
void WM_drag_add_ID(struct wmDrag *drag, struct ID *id, struct ID *from_parent);
|
|
|
|
|
struct ID *WM_drag_ID(const struct wmDrag *drag, short idcode);
|
|
|
|
|
struct ID *WM_drag_ID_from_event(const struct wmEvent *event, short idcode);
|
|
|
|
|
|
2018-02-16 22:41:46 +01:00
|
|
|
/* Set OpenGL viewport and scissor */
|
|
|
|
|
void wmViewport(const struct rcti *rect);
|
|
|
|
|
void wmPartialViewport(rcti *drawrct, const rcti *winrct, const rcti *partialrct);
|
|
|
|
|
void wmWindowViewport(struct wmWindow *win);
|
2008-12-19 14:14:43 +00:00
|
|
|
|
2017-03-22 15:52:48 -04:00
|
|
|
/* OpenGL utilities with safety check */
|
2008-12-19 14:14:43 +00:00
|
|
|
void wmOrtho2 (float x1, float x2, float y1, float y2);
|
2014-09-10 13:24:31 +10:00
|
|
|
/* use for conventions (avoid hard-coded offsets all over) */
|
|
|
|
|
void wmOrtho2_region_pixelspace(const struct ARegion *ar);
|
|
|
|
|
void wmOrtho2_pixelspace(const float x, const float y);
|
2018-02-16 22:41:46 +01:00
|
|
|
void wmGetProjectionMatrix(float mat[4][4], const struct rcti *winrct);
|
2008-01-01 15:53:38 +00:00
|
|
|
|
2.5
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
2009-01-22 14:59:49 +00:00
|
|
|
/* threaded Jobs Manager */
|
2012-08-15 09:42:06 +00:00
|
|
|
enum {
|
|
|
|
|
WM_JOB_PRIORITY = (1 << 0),
|
|
|
|
|
WM_JOB_EXCL_RENDER = (1 << 1),
|
|
|
|
|
WM_JOB_PROGRESS = (1 << 2),
|
|
|
|
|
WM_JOB_SUSPEND = (1 << 3)
|
|
|
|
|
};
|
|
|
|
|
|
2012-11-06 15:54:04 +00:00
|
|
|
/* identifying jobs by owner alone is unreliable, this isnt saved, order can change (keep 0 for 'any') */
|
2012-08-15 09:42:06 +00:00
|
|
|
enum {
|
2012-11-06 15:54:04 +00:00
|
|
|
WM_JOB_TYPE_ANY = 0,
|
2012-08-15 09:42:06 +00:00
|
|
|
WM_JOB_TYPE_COMPOSITE,
|
|
|
|
|
WM_JOB_TYPE_RENDER,
|
|
|
|
|
WM_JOB_TYPE_RENDER_PREVIEW, /* UI preview */
|
|
|
|
|
WM_JOB_TYPE_OBJECT_SIM_OCEAN,
|
2012-08-15 10:03:29 +00:00
|
|
|
WM_JOB_TYPE_OBJECT_SIM_FLUID,
|
2012-08-15 09:42:06 +00:00
|
|
|
WM_JOB_TYPE_OBJECT_BAKE_TEXTURE,
|
2014-05-08 21:46:51 -03:00
|
|
|
WM_JOB_TYPE_OBJECT_BAKE,
|
Final 'FileBrowser First Stage' merge.
It basically rewrites most of filelist.c, with some more limited changes in other areas of filebrowser.
From user perspective, it:
* Removes some info in 'long' drawing mode (owner, permissions) - OS-specific data that do not really matter in Blender!
* Makes short/long display 'fixed' size (among four choices, like thumbnails mode).
* Allows to list several layers of dirtree at once, in a flat way (inside .blend files and/or real directories).
* Consequently, adds datablocks types filtering.
* Uses way less RAM when listing big directories, especially in thumbnail mode (we are talking of several hundred of MiB spared).
* Generates thumbnails way faster.
From code perspective, it:
* Is ready for asset engine needs (on data structure level in filebrowser's listing).
* Simplifies and makes 'generic' file listing much lighter.
* Separates file listing in three different aspects:
** 'generic' filelisting (in BLI), which becomes a shallow wrapper around stat struct.
** 'filebrowser drawing' filelisting, which only contains current visible subset of the whole list (sliding window), with extra drawing data (strings for size, date/time, preview, etc.).
** 'asset-ready' filelisting, which is used for operations common to 'basic' filehandling and future asset-related one.
* Uses uuid's to handle file selection/state in the browser, instead of using flags in filelisting items.
* Uses much lighter BLI_task handling for previews, instead of heavy 'job' system (using the new 'notifier' timer to handle UI refresh, in similar way to jobs).
* Moves .blend datablocks preview handling to IMB_thumbnail (necessary to avoid storing all datablock previews at once, and gives better consistency and performances too).
Revision: https://developer.blender.org/D1316
Thanks to Campbell & Sergey for the reviews. :)
2015-08-19 22:41:39 +02:00
|
|
|
WM_JOB_TYPE_FILESEL_READDIR,
|
2012-08-15 09:42:06 +00:00
|
|
|
WM_JOB_TYPE_CLIP_BUILD_PROXY,
|
|
|
|
|
WM_JOB_TYPE_CLIP_TRACK_MARKERS,
|
|
|
|
|
WM_JOB_TYPE_CLIP_SOLVE_CAMERA,
|
2013-03-20 17:03:20 +00:00
|
|
|
WM_JOB_TYPE_CLIP_PREFETCH,
|
2012-08-15 09:42:06 +00:00
|
|
|
WM_JOB_TYPE_SEQ_BUILD_PROXY,
|
2014-11-24 18:18:35 +01:00
|
|
|
WM_JOB_TYPE_SEQ_BUILD_PREVIEW,
|
2016-01-17 02:01:41 +01:00
|
|
|
WM_JOB_TYPE_POINTCACHE,
|
2016-01-17 02:04:46 +01:00
|
|
|
WM_JOB_TYPE_DPAINT_BAKE,
|
Basic Alembic support
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060
2016-08-06 06:20:37 +02:00
|
|
|
WM_JOB_TYPE_ALEMBIC,
|
2018-03-05 21:50:56 +01:00
|
|
|
WM_JOB_TYPE_SHADER_COMPILATION,
|
2018-06-19 14:07:21 +02:00
|
|
|
WM_JOB_TYPE_STUDIOLIGHT,
|
2018-07-10 15:02:25 +02:00
|
|
|
WM_JOB_TYPE_LIGHT_BAKE,
|
2012-08-15 09:42:06 +00:00
|
|
|
/* add as needed, screencast, seq proxy build
|
|
|
|
|
* if having hard coded values is a problem */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct wmJob *WM_jobs_get(struct wmWindowManager *wm, struct wmWindow *win, void *owner, const char *name, int flag, int job_type);
|
|
|
|
|
|
2013-12-05 17:26:03 +11:00
|
|
|
bool WM_jobs_test(struct wmWindowManager *wm, void *owner, int job_type);
|
2010-05-27 08:22:16 +00:00
|
|
|
float WM_jobs_progress(struct wmWindowManager *wm, void *owner);
|
2012-08-12 21:46:35 +00:00
|
|
|
char *WM_jobs_name(struct wmWindowManager *wm, void *owner);
|
2016-01-18 01:39:09 +01:00
|
|
|
double WM_jobs_starttime(struct wmWindowManager *wm, void *owner);
|
2013-08-28 19:22:48 +00:00
|
|
|
void *WM_jobs_customdata(struct wmWindowManager *wm, void *owner);
|
2013-10-31 17:20:31 +00:00
|
|
|
void *WM_jobs_customdata_from_type(struct wmWindowManager *wm, int job_type);
|
2009-01-27 17:12:40 +00:00
|
|
|
|
2013-12-05 17:26:03 +11:00
|
|
|
bool WM_jobs_is_running(struct wmJob *);
|
2016-01-18 01:39:09 +01:00
|
|
|
bool WM_jobs_is_stopped(wmWindowManager *wm, void *owner);
|
2012-08-12 21:46:35 +00:00
|
|
|
void *WM_jobs_customdata_get(struct wmJob *);
|
2012-08-11 21:35:24 +00:00
|
|
|
void WM_jobs_customdata_set(struct wmJob *, void *customdata, void (*free)(void *));
|
2012-07-31 23:06:12 +00:00
|
|
|
void WM_jobs_timer(struct wmJob *, double timestep, unsigned int note, unsigned int endnote);
|
|
|
|
|
void WM_jobs_callbacks(struct wmJob *,
|
|
|
|
|
void (*startjob)(void *, short *, short *, float *),
|
|
|
|
|
void (*initjob)(void *),
|
|
|
|
|
void (*update)(void *),
|
|
|
|
|
void (*endjob)(void *));
|
2.5
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
2009-01-22 14:59:49 +00:00
|
|
|
|
2009-06-07 11:12:35 +00:00
|
|
|
void WM_jobs_start(struct wmWindowManager *wm, struct wmJob *);
|
2010-07-04 19:58:52 +00:00
|
|
|
void WM_jobs_stop(struct wmWindowManager *wm, void *owner, void *startjob);
|
2010-12-03 01:52:28 +00:00
|
|
|
void WM_jobs_kill(struct wmWindowManager *wm, void *owner, void (*)(void *, short int *, short int *, float *));
|
2012-10-29 17:41:19 +00:00
|
|
|
void WM_jobs_kill_all(struct wmWindowManager *wm);
|
2012-11-28 09:36:23 +00:00
|
|
|
void WM_jobs_kill_all_except(struct wmWindowManager *wm, void *owner);
|
2013-09-23 19:35:21 +00:00
|
|
|
void WM_jobs_kill_type(struct wmWindowManager *wm, void *owner, int job_type);
|
2012-11-28 09:36:23 +00:00
|
|
|
|
2013-12-05 17:26:03 +11:00
|
|
|
bool WM_jobs_has_running(struct wmWindowManager *wm);
|
2011-11-29 15:26:46 +00:00
|
|
|
|
2013-07-08 17:56:51 +00:00
|
|
|
void WM_job_main_thread_lock_acquire(struct wmJob *job);
|
|
|
|
|
void WM_job_main_thread_lock_release(struct wmJob *job);
|
|
|
|
|
|
2.5: Text Editor back.
There was very little structure in this code, using many globals
and duplicated code. Now it should be better structured. Most
things should work, the main parts that are not back yet are the
python plugins and markers. Notes:
* Blenfont is used for drawing the text, nicely anti-aliased.
* A monospace truetype font was added, since that is needed for
the text editor. It's Bitstream Vera Sans Mono. This is the
default gnome terminal font, but it doesn't fit entirely well
with the other font I think, can be changed easily of course.
* Clipboard copy/cut/paste now always uses the system clipboard,
the code for the own cut buffer was removed.
* The interface buttons should support copy/cut/paste again now
as well.
* WM_clipboard_text_get/WM_clipboard_text_set were added to the
windowmanager code.
* Find panel is now a kind of second header, instead of a panel.
This needs especially a way to start editing the text field
immediately on open still.
* Operators are independent of the actual space when possible,
was a bit of puzzling but got it solved nice with notifiers,
and some lazy init for syntax highlight in the drawing code.
* RNA was created for the text editor space and used for buttons.
* Operators:
* New, Open, Reload, Save, Save As, Make Internal
* Run Script, Refresh Pyconstraints
* Copy, Cut, Paste
* Convert Whitespace, Uncomment, Comment, Indent, Unindent
* Line Break, Insert
* Next Marker, Previous Marker, Clear All Markers, Mark All
* Select Line, Select All
* Jump, Move, Move Select, Delete, Toggle Overwrite
* Scroll, Scroll Bar, Set Cursor, Line Number
* Find and Replace, Find, Replace, Find Set Selected,
Replace Set Selected
* To 3D Object
* Resolve Conflict
2009-02-28 23:33:35 +00:00
|
|
|
/* clipboard */
|
2014-01-08 17:39:12 +11:00
|
|
|
char *WM_clipboard_text_get(bool selection, int *r_len);
|
|
|
|
|
char *WM_clipboard_text_get_firstline(bool selection, int *r_len);
|
2013-12-05 17:26:03 +11:00
|
|
|
void WM_clipboard_text_set(const char *buf, bool selection);
|
2.5: Text Editor back.
There was very little structure in this code, using many globals
and duplicated code. Now it should be better structured. Most
things should work, the main parts that are not back yet are the
python plugins and markers. Notes:
* Blenfont is used for drawing the text, nicely anti-aliased.
* A monospace truetype font was added, since that is needed for
the text editor. It's Bitstream Vera Sans Mono. This is the
default gnome terminal font, but it doesn't fit entirely well
with the other font I think, can be changed easily of course.
* Clipboard copy/cut/paste now always uses the system clipboard,
the code for the own cut buffer was removed.
* The interface buttons should support copy/cut/paste again now
as well.
* WM_clipboard_text_get/WM_clipboard_text_set were added to the
windowmanager code.
* Find panel is now a kind of second header, instead of a panel.
This needs especially a way to start editing the text field
immediately on open still.
* Operators are independent of the actual space when possible,
was a bit of puzzling but got it solved nice with notifiers,
and some lazy init for syntax highlight in the drawing code.
* RNA was created for the text editor space and used for buttons.
* Operators:
* New, Open, Reload, Save, Save As, Make Internal
* Run Script, Refresh Pyconstraints
* Copy, Cut, Paste
* Convert Whitespace, Uncomment, Comment, Indent, Unindent
* Line Break, Insert
* Next Marker, Previous Marker, Clear All Markers, Mark All
* Select Line, Select All
* Jump, Move, Move Select, Delete, Toggle Overwrite
* Scroll, Scroll Bar, Set Cursor, Line Number
* Find and Replace, Find, Replace, Find Set Selected,
Replace Set Selected
* To 3D Object
* Resolve Conflict
2009-02-28 23:33:35 +00:00
|
|
|
|
2010-06-01 20:21:40 +00:00
|
|
|
/* progress */
|
|
|
|
|
void WM_progress_set(struct wmWindow *win, float progress);
|
|
|
|
|
void WM_progress_clear(struct wmWindow *win);
|
|
|
|
|
|
2011-12-05 16:37:31 +00:00
|
|
|
/* Draw (for screenshot) */
|
2018-01-19 17:14:27 +11:00
|
|
|
void *WM_draw_cb_activate(
|
|
|
|
|
struct wmWindow *win,
|
2018-01-19 17:31:10 +11:00
|
|
|
void (*draw)(const struct wmWindow *, void *),
|
2018-01-19 17:14:27 +11:00
|
|
|
void *customdata);
|
|
|
|
|
void WM_draw_cb_exit(struct wmWindow *win, void *handle);
|
2011-12-05 16:37:31 +00:00
|
|
|
void WM_redraw_windows(struct bContext *C);
|
|
|
|
|
|
2018-04-27 10:22:37 +02:00
|
|
|
/* Region drawing */
|
|
|
|
|
void WM_draw_region_free(struct ARegion *ar);
|
|
|
|
|
struct GPUViewport *WM_draw_region_get_viewport(struct ARegion *ar, int view);
|
|
|
|
|
struct GPUViewport *WM_draw_region_get_bound_viewport(struct ARegion *ar);
|
|
|
|
|
|
2012-09-15 01:52:28 +00:00
|
|
|
void WM_main_playanim(int argc, const char **argv);
|
|
|
|
|
|
2011-02-14 03:15:55 +00:00
|
|
|
/* debugging only, convenience function to write on crash */
|
2013-12-05 17:26:03 +11:00
|
|
|
bool write_crash_blend(void);
|
2011-02-14 03:15:55 +00:00
|
|
|
|
Option to lock the interface while rendering
Added function called WM_set_locked_interface which does
two things:
- Prevents event queue from being handled, so no operators
(see below) or values are even possible to run or change.
This prevents any kind of "destructive" action performed
from user while rendering.
- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.
This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.
Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.
For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.
Other tools like backing would also benefit of this option.
It is possible to mark operator as safe to be used in locked
interface mode by adding OPTYPE_ALLOW_LOCKED bit to operator
template flags.
This bit is completely handled by wm_evem_system, not
with operator run routines, so it's still possible to
run operators from drivers and handlers.
Currently allowed image editor navigation and zooming.
Reviewers: brecht, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D142
2014-01-29 16:07:14 +06:00
|
|
|
/* Lock the interface for any communication */
|
|
|
|
|
void WM_set_locked_interface(struct wmWindowManager *wm, bool lock);
|
|
|
|
|
|
2016-08-18 00:21:55 -04:00
|
|
|
#ifdef WITH_INPUT_NDOF
|
2014-02-18 23:51:11 +11:00
|
|
|
void WM_event_ndof_pan_get(const struct wmNDOFMotionData *ndof, float r_pan[3], const bool use_zoom);
|
|
|
|
|
void WM_event_ndof_rotate_get(const struct wmNDOFMotionData *ndof, float r_rot[3]);
|
|
|
|
|
|
|
|
|
|
float WM_event_ndof_to_axis_angle(const struct wmNDOFMotionData *ndof, float axis[3]);
|
|
|
|
|
void WM_event_ndof_to_quat(const struct wmNDOFMotionData *ndof, float q[4]);
|
2016-08-18 00:21:55 -04:00
|
|
|
#endif /* WITH_INPUT_NDOF */
|
2014-02-18 23:51:11 +11:00
|
|
|
|
2014-07-14 17:49:00 +03:00
|
|
|
float WM_event_tablet_data(const struct wmEvent *event, int *pen_flip, float tilt[2]);
|
|
|
|
|
bool WM_event_is_tablet(const struct wmEvent *event);
|
2014-07-14 16:59:35 +03:00
|
|
|
|
2014-12-07 00:58:17 +01:00
|
|
|
#ifdef WITH_INPUT_IME
|
|
|
|
|
bool WM_event_is_ime_switch(const struct wmEvent *event);
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-06-26 12:18:54 +02:00
|
|
|
const char *WM_window_cursor_keymap_status_get(const struct wmWindow *win, int button_index, int type_index);
|
|
|
|
|
void WM_window_cursor_keymap_status_refresh(struct bContext *C, struct wmWindow *win);
|
|
|
|
|
|
2018-07-09 18:13:13 +02:00
|
|
|
void WM_window_status_area_tag_redraw(struct wmWindow *win);
|
|
|
|
|
struct ScrArea *WM_window_status_area_find(struct wmWindow *win, struct bScreen *sc);
|
2018-07-05 12:09:17 +02:00
|
|
|
bool WM_window_modal_keymap_status_draw(
|
|
|
|
|
struct bContext *C, struct wmWindow *win,
|
|
|
|
|
struct uiLayout *layout);
|
|
|
|
|
|
2018-01-25 16:17:25 +11:00
|
|
|
/* wm_tooltip.c */
|
|
|
|
|
typedef struct ARegion *(*wmTooltipInitFn)(struct bContext *, struct ARegion *, bool *);
|
|
|
|
|
|
|
|
|
|
void WM_tooltip_timer_init(
|
|
|
|
|
struct bContext *C, struct wmWindow *win, struct ARegion *ar,
|
|
|
|
|
wmTooltipInitFn init);
|
|
|
|
|
void WM_tooltip_timer_clear(struct bContext *C, struct wmWindow *win);
|
|
|
|
|
void WM_tooltip_clear(struct bContext *C, struct wmWindow *win);
|
|
|
|
|
void WM_tooltip_init(struct bContext *C, struct wmWindow *win);
|
|
|
|
|
void WM_tooltip_refresh(struct bContext *C, struct wmWindow *win);
|
|
|
|
|
|
2010-10-05 00:05:14 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#endif /* __WM_API_H__ */
|
