tornavis/source/blender/blenkernel/BKE_screen.hh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

649 lines
22 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2001-2002 NaN Holding BV. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
2002-10-12 13:37:38 +02:00
/** \file
* \ingroup bke
*/
#include "BLI_compiler_attrs.h"
#include "RNA_types.hh"
#include "BKE_context.h"
namespace blender::asset_system {
class AssetRepresentation;
}
struct ARegion;
2020-11-06 00:29:00 +01:00
struct BlendDataReader;
struct BlendLibReader;
struct BlendWriter;
struct Header;
2015-12-01 02:55:57 +01:00
struct ID;
Performance: Remap multiple items in UI During sprite fright loading of complex scenes would spend a long time in remapping ID's The remapping process is done on a per ID instance that resulted in a very time consuming process that goes over every possible ID reference to find out if it needs to be updated. If there are N of references to ID blocks and there are M ID blocks that needed to be remapped it would take N*M checks. These checks are scattered around the place and memory. Each reference would only be updated at most once, but most of the time no update is needed at all. Idea: By grouping the changes together will reduce the number of checks resulting in improved performance. This would only require N checks. Additional benefits is improved data locality as data is only loaded once in the L2 cache. It has be implemented for the resyncing process and UI editors. On an Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz 16Gig the resyncing process went from 170 seconds to 145 seconds (during hotspot recording). After this patch has been applied we could add similar approach to references (references between data blocks) and functionality (tagged deletion). In my understanding this could reduce the resyncing process to less than a second. Opening the village production file between 10 and 20 seconds. Flame graphs showing that UI remapping isn't visible anymore (`WM_main_remap_editor_id_reference`) * Master {F12769210 size=full} * This patch {F12769211 size=full} Reviewed By: mont29 Maniphest Tasks: T94185 Differential Revision: https://developer.blender.org/D13615
2022-01-25 14:51:35 +01:00
struct IDRemapper;
2020-05-27 02:52:07 +02:00
struct LibraryForeachIDData;
struct ListBase;
struct Menu;
struct Panel;
struct Scene;
struct ScrArea;
struct ScrAreaMap;
struct ScrEdge;
struct ScrVert;
struct SpaceType;
struct View3D;
struct View3DShading;
struct WorkSpace;
struct bContext;
struct bScreen;
struct uiLayout;
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 10:20:16 +01:00
struct uiList;
struct wmGizmoMap;
struct wmKeyConfig;
struct wmMsgBus;
struct wmNotifier;
struct wmWindow;
struct wmWindowManager;
/* spacetype has everything stored to get an editor working, it gets initialized via
* #ED_spacetypes_init() in `editors/space_api/spacetypes.cc` */
/* an editor in Blender is a combined ScrArea + SpaceType + SpaceData */
#define BKE_ST_MAXNAME 64
struct wmSpaceTypeListenerParams {
wmWindow *window;
ScrArea *area;
const wmNotifier *notifier;
const Scene *scene;
};
struct SpaceType {
SpaceType *next, *prev;
char name[BKE_ST_MAXNAME]; /* for menus */
int spaceid; /* unique space identifier */
int iconid; /* icon lookup for menus */
/* Initial allocation, after this WM will call init() too. Some editors need
* area and scene data (e.g. frame range) to set their initial scrolling. */
SpaceLink *(*create)(const ScrArea *area, const Scene *scene);
2.5 Branch ========== * Changed wmOperatorType, removing init/exit callbacks and adding cancel callback, removed default storage in favor of properties. Defined return values for exec/invoke/modal/cancel. * Don't allocate operator on the stack, and removed operator copy for handlers. Now it frees based on return values from callbacks, and just keeps a wmOperator on the heap. Also it now registers after the operator is fully finished, to get the correct final properties. * Changed OP_get_* functions to return 1 if the property is found and 0 otherwise, gives more readable code in my opinion. Added OP_verify_* functions to quickly check if the property is available and set if it's not, that's common for exec/invoke. * Removed WM_operatortypelist_append in favor of WM_operatortype_append which takes a function pointer instead of a list, avoids macro's and duplicating code. * Fix a crash where the handler would still be used while it was freed by the operator. * Spacetypes now have operatortypes() and keymap() callbacks to abstract them a bit more. * Renamed C->curarea to C->area for consistency. Removed View3D/View2D/ SpaceIpo from bContext, seems bad to keep these. * Set context variables like window/screen/area/region to NULL again when leaving that context, instead of leaving the pointers there. * Added if(G.f & G_DEBUG) for many of the prints, makes output a bit cleaner and easier to debug. * Fixed priority of the editors/interface module in scons, would otherwise give link errors. * Added start of generic view2d api. * Added space_time with some basic drawing and a single operator to change the frame.
2008-06-11 12:10:31 +02:00
/* not free spacelink itself */
void (*free)(SpaceLink *sl);
/* init is to cope with file load, screen (size) changes, check handlers */
void (*init)(wmWindowManager *wm, ScrArea *area);
/* exit is called when the area is hidden or removed */
void (*exit)(wmWindowManager *wm, ScrArea *area);
/* Listeners can react to bContext changes */
void (*listener)(const wmSpaceTypeListenerParams *params);
/* called when the mouse moves out of the area */
void (*deactivate)(ScrArea *area);
2023-09-05 02:49:20 +02:00
/** Refresh context, called after file-reads, #ED_area_tag_refresh(). */
void (*refresh)(const bContext *C, ScrArea *area);
2.5 Branch ========== * Changed wmOperatorType, removing init/exit callbacks and adding cancel callback, removed default storage in favor of properties. Defined return values for exec/invoke/modal/cancel. * Don't allocate operator on the stack, and removed operator copy for handlers. Now it frees based on return values from callbacks, and just keeps a wmOperator on the heap. Also it now registers after the operator is fully finished, to get the correct final properties. * Changed OP_get_* functions to return 1 if the property is found and 0 otherwise, gives more readable code in my opinion. Added OP_verify_* functions to quickly check if the property is available and set if it's not, that's common for exec/invoke. * Removed WM_operatortypelist_append in favor of WM_operatortype_append which takes a function pointer instead of a list, avoids macro's and duplicating code. * Fix a crash where the handler would still be used while it was freed by the operator. * Spacetypes now have operatortypes() and keymap() callbacks to abstract them a bit more. * Renamed C->curarea to C->area for consistency. Removed View3D/View2D/ SpaceIpo from bContext, seems bad to keep these. * Set context variables like window/screen/area/region to NULL again when leaving that context, instead of leaving the pointers there. * Added if(G.f & G_DEBUG) for many of the prints, makes output a bit cleaner and easier to debug. * Fixed priority of the editors/interface module in scons, would otherwise give link errors. * Added start of generic view2d api. * Added space_time with some basic drawing and a single operator to change the frame.
2008-06-11 12:10:31 +02:00
/* after a spacedata copy, an init should result in exact same situation */
SpaceLink *(*duplicate)(SpaceLink *sl);
2.5 Branch ========== * Changed wmOperatorType, removing init/exit callbacks and adding cancel callback, removed default storage in favor of properties. Defined return values for exec/invoke/modal/cancel. * Don't allocate operator on the stack, and removed operator copy for handlers. Now it frees based on return values from callbacks, and just keeps a wmOperator on the heap. Also it now registers after the operator is fully finished, to get the correct final properties. * Changed OP_get_* functions to return 1 if the property is found and 0 otherwise, gives more readable code in my opinion. Added OP_verify_* functions to quickly check if the property is available and set if it's not, that's common for exec/invoke. * Removed WM_operatortypelist_append in favor of WM_operatortype_append which takes a function pointer instead of a list, avoids macro's and duplicating code. * Fix a crash where the handler would still be used while it was freed by the operator. * Spacetypes now have operatortypes() and keymap() callbacks to abstract them a bit more. * Renamed C->curarea to C->area for consistency. Removed View3D/View2D/ SpaceIpo from bContext, seems bad to keep these. * Set context variables like window/screen/area/region to NULL again when leaving that context, instead of leaving the pointers there. * Added if(G.f & G_DEBUG) for many of the prints, makes output a bit cleaner and easier to debug. * Fixed priority of the editors/interface module in scons, would otherwise give link errors. * Added start of generic view2d api. * Added space_time with some basic drawing and a single operator to change the frame.
2008-06-11 12:10:31 +02:00
/* register operator types on startup */
void (*operatortypes)();
/* add default items to WM keymap */
void (*keymap)(wmKeyConfig *keyconf);
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 19:18:21 +01:00
/* on startup, define dropboxes for spacetype+regions */
void (*dropboxes)();
2.5 Branch ========== * Changed wmOperatorType, removing init/exit callbacks and adding cancel callback, removed default storage in favor of properties. Defined return values for exec/invoke/modal/cancel. * Don't allocate operator on the stack, and removed operator copy for handlers. Now it frees based on return values from callbacks, and just keeps a wmOperator on the heap. Also it now registers after the operator is fully finished, to get the correct final properties. * Changed OP_get_* functions to return 1 if the property is found and 0 otherwise, gives more readable code in my opinion. Added OP_verify_* functions to quickly check if the property is available and set if it's not, that's common for exec/invoke. * Removed WM_operatortypelist_append in favor of WM_operatortype_append which takes a function pointer instead of a list, avoids macro's and duplicating code. * Fix a crash where the handler would still be used while it was freed by the operator. * Spacetypes now have operatortypes() and keymap() callbacks to abstract them a bit more. * Renamed C->curarea to C->area for consistency. Removed View3D/View2D/ SpaceIpo from bContext, seems bad to keep these. * Set context variables like window/screen/area/region to NULL again when leaving that context, instead of leaving the pointers there. * Added if(G.f & G_DEBUG) for many of the prints, makes output a bit cleaner and easier to debug. * Fixed priority of the editors/interface module in scons, would otherwise give link errors. * Added start of generic view2d api. * Added space_time with some basic drawing and a single operator to change the frame.
2008-06-11 12:10:31 +02:00
/* initialize gizmo-map-types and gizmo-group-types with the region */
void (*gizmos)();
/* return context data */
bContextDataCallback context;
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
/* Used when we want to replace an ID by another (or NULL). */
void (*id_remap)(ScrArea *area, SpaceLink *sl, const IDRemapper *mappings);
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
/**
* foreach_id callback to process all ID pointers of the editor. Used indirectly by lib_query's
2023-08-18 00:51:29 +02:00
* #BKE_library_foreach_ID_link when #IDWALK_INCLUDE_UI bit-flag is set (through WM's foreach_id
* usage of #BKE_screen_foreach_id_screen_area).
*/
void (*foreach_id)(SpaceLink *space_link, LibraryForeachIDData *data);
int (*space_subtype_get)(ScrArea *area);
void (*space_subtype_set)(ScrArea *area, int value);
void (*space_subtype_item_extend)(bContext *C, EnumPropertyItem **item, int *totitem);
/**
* Update pointers for all structs directly owned by this space.
*/
void (*blend_read_data)(BlendDataReader *reader, SpaceLink *space_link);
/**
* Update pointers to other id data blocks.
*/
void (*blend_read_after_liblink)(BlendLibReader *reader, ID *parent_id, SpaceLink *space_link);
/**
* Write all structs that should be saved in a .blend file.
*/
void (*blend_write)(BlendWriter *writer, SpaceLink *space_link);
/* region type definitions */
ListBase regiontypes;
/** Asset shelf type definitions. */
ListBase asset_shelf_types; /* #AssetShelfType */
/* read and write... */
2022-09-16 10:13:19 +02:00
/** Default key-maps to add. */
int keymapflag;
};
/* region types are also defined using spacetypes_init, via a callback */
struct wmRegionListenerParams {
wmWindow *window;
ScrArea *area; /* Can be NULL when the region is not part of an area. */
ARegion *region;
const wmNotifier *notifier;
const Scene *scene;
};
struct wmRegionMessageSubscribeParams {
const bContext *context;
wmMsgBus *message_bus;
WorkSpace *workspace;
Scene *scene;
bScreen *screen;
ScrArea *area;
ARegion *region;
};
struct RegionPollParams {
const bScreen *screen;
const ScrArea *area;
const ARegion *region;
UI: Region polling support Introduces *ARegionType.poll()* as a way to dynamically add/remove a region. The region is still there internally, but is not accessible to the user. Previously editors would to this manually, by either removing/adding regions altogether, or hiding them, unsetting their alignment (so no AZones are added I assume) and removing their event handlers. Polling makes this much simpler. We plan to use this in #102879. This patch refactors multiple editors to use region polling: - File Browser - Sequencer - Clip Editor - Preferences Notes: - Previously, editors would lazy-create some of the regions. Versioning is added here to ensure they are always there. Could be a separate patch. - Some editors reuse a region in different display modes, and so additional work needs to be done to reinit regions they become available or the mode changes. Typically `V2D_IS_INIT` is unset for that, which isn't great. Could be improved, but not a new issue. Behavior change: - When the Preferences are opened as a regular editor, the "execution" region in the preferences that displays the *Save Preferences* button would still be there, but empty with a scrollbar. This patch makes it disappear entirely. ## Implementation - Introduces `ARegionType.poll()` - Before a window is drawn, all contained regions have their poll checked, and the result is stored in a flag (`RGN_FLAG_POLL_FAILED` - runtime-only flag). - If the result of the poll changes, the area is re-initialized and event handlers are added/removed. - UI code checks the flag as needed. Pull Request: https://projects.blender.org/blender/blender/pulls/105088
2023-04-05 15:30:32 +02:00
/** Full context, if WM context above is not enough. */
const bContext *context;
};
UI: Region polling support Introduces *ARegionType.poll()* as a way to dynamically add/remove a region. The region is still there internally, but is not accessible to the user. Previously editors would to this manually, by either removing/adding regions altogether, or hiding them, unsetting their alignment (so no AZones are added I assume) and removing their event handlers. Polling makes this much simpler. We plan to use this in #102879. This patch refactors multiple editors to use region polling: - File Browser - Sequencer - Clip Editor - Preferences Notes: - Previously, editors would lazy-create some of the regions. Versioning is added here to ensure they are always there. Could be a separate patch. - Some editors reuse a region in different display modes, and so additional work needs to be done to reinit regions they become available or the mode changes. Typically `V2D_IS_INIT` is unset for that, which isn't great. Could be improved, but not a new issue. Behavior change: - When the Preferences are opened as a regular editor, the "execution" region in the preferences that displays the *Save Preferences* button would still be there, but empty with a scrollbar. This patch makes it disappear entirely. ## Implementation - Introduces `ARegionType.poll()` - Before a window is drawn, all contained regions have their poll checked, and the result is stored in a flag (`RGN_FLAG_POLL_FAILED` - runtime-only flag). - If the result of the poll changes, the area is re-initialized and event handlers are added/removed. - UI code checks the flag as needed. Pull Request: https://projects.blender.org/blender/blender/pulls/105088
2023-04-05 15:30:32 +02:00
struct ARegionType {
ARegionType *next, *prev;
int regionid; /* unique identifier within this space, defines RGN_TYPE_xxxx */
/* add handlers, stuff you only do once or on area/region type/size changes */
void (*init)(wmWindowManager *wm, ARegion *region);
/* exit is called when the region is hidden or removed */
void (*exit)(wmWindowManager *wm, ARegion *region);
UI: Region polling support Introduces *ARegionType.poll()* as a way to dynamically add/remove a region. The region is still there internally, but is not accessible to the user. Previously editors would to this manually, by either removing/adding regions altogether, or hiding them, unsetting their alignment (so no AZones are added I assume) and removing their event handlers. Polling makes this much simpler. We plan to use this in #102879. This patch refactors multiple editors to use region polling: - File Browser - Sequencer - Clip Editor - Preferences Notes: - Previously, editors would lazy-create some of the regions. Versioning is added here to ensure they are always there. Could be a separate patch. - Some editors reuse a region in different display modes, and so additional work needs to be done to reinit regions they become available or the mode changes. Typically `V2D_IS_INIT` is unset for that, which isn't great. Could be improved, but not a new issue. Behavior change: - When the Preferences are opened as a regular editor, the "execution" region in the preferences that displays the *Save Preferences* button would still be there, but empty with a scrollbar. This patch makes it disappear entirely. ## Implementation - Introduces `ARegionType.poll()` - Before a window is drawn, all contained regions have their poll checked, and the result is stored in a flag (`RGN_FLAG_POLL_FAILED` - runtime-only flag). - If the result of the poll changes, the area is re-initialized and event handlers are added/removed. - UI code checks the flag as needed. Pull Request: https://projects.blender.org/blender/blender/pulls/105088
2023-04-05 15:30:32 +02:00
/**
* Optional callback to decide whether the region should be treated as existing given the
* current context. When returning false, the region will be kept in storage, but is not
* available to the user in any way. Callbacks can assume that context has the owning area and
* space-data set.
*/
bool (*poll)(const RegionPollParams *params);
/* draw entirely, view changes should be handled here */
void (*draw)(const bContext *C, ARegion *region);
/**
* Handler to draw overlays. This handler is called every draw loop.
*
* \note Some editors should return early if the interface is locked
* (check with #CTX_wm_interface_locked) to avoid accessing scene data
* that another thread may be modifying
*/
void (*draw_overlay)(const bContext *C, ARegion *region);
/* optional, compute button layout before drawing for dynamic size */
void (*layout)(const bContext *C, ARegion *region);
/* snap the size of the region (can be NULL for no snapping). */
int (*snap_size)(const ARegion *region, int size, int axis);
/* contextual changes should be handled here */
void (*listener)(const wmRegionListenerParams *params);
/* Optional callback to generate subscriptions. */
void (*message_subscribe)(const wmRegionMessageSubscribeParams *params);
void (*free)(ARegion *);
/* split region, copy data optionally */
void *(*duplicate)(void *poin);
/* register operator types on startup */
void (*operatortypes)();
/* add own items to keymap */
void (*keymap)(wmKeyConfig *keyconf);
/* allows default cursor per region */
void (*cursor)(wmWindow *win, ScrArea *area, ARegion *region);
/* return context data */
bContextDataCallback context;
/**
* Called whenever the user changes the region's size. Not called when the size is changed
* through other means, like to adjust for a scaled down window.
*/
void (*on_user_resize)(const ARegion *region);
/* Is called whenever the current visible View2D's region changes.
*
* Used from user code such as view navigation/zoom operators to inform region about changes.
* The goal is to support zoom-to-fit features which gets disabled when manual navigation is
* performed.
*
* This callback is not called on indirect changes of the current viewport (which could happen
* when the `v2d->tot is changed and `cur` is adopted accordingly). */
void (*on_view2d_changed)(const bContext *C, ARegion *region);
/* custom drawing callbacks */
ListBase drawcalls;
/* panels type definitions */
ListBase paneltypes;
/* header type definitions */
ListBase headertypes;
/* hardcoded constraints, smaller than these values region is not visible */
int minsizex, minsizey;
Drag and drop 2.5 integration! Finally, slashdot regulars can use Blender too now! :) ** Drag works as follows: - drag-able items are defined by the standard interface ui toolkit - each button can get this feature, via uiButSetDragXXX(but, ...). There are calls to define drag-able images, ID blocks, RNA paths, file paths, and so on. By default you drag an icon, exceptionally an ImBuf - Drag items are registered centrally in the WM, it allows more drag items simultaneous too, but not implemented ** Drop works as follows: - On mouse release, and if drag items exist in the WM, it converts the mouse event to an EVT_DROP type. This event then gets the full drag info as customdata - drop regions are defined with WM_dropbox_add(), similar to keymaps you can make a "drop map" this way, which become 'drop map handlers' in the queues. - next to that the UI kit handles some common button types (like accepting ID or names) to be catching a drop event too. - Every "drop box" has two callbacks: - poll() = check if the event drag data is relevant for this box - copy() = fill in custom properties in the dropbox to initialize an operator - The dropbox handler then calls its standard Operator with its dropbox properties. ** Currently implemented Drag items: - ID icons in browse buttons - ID icons in context menu of properties region - ID icons in outliner and rna viewer - FileBrowser icons - FileBrowser preview images Drag-able icons are subtly visualized by making them brighter a bit on mouse-over. In case the icon is a button or UI element too (most cases), the drag-able feature will make the item react to mouse-release instead of mouse-press. Drop options: - UI buttons: ID and text buttons (paste name) - View3d: Object ID drop copies object - View3d: Material ID drop assigns to object under cursor - View3d: Image ID drop assigns to object UV texture under cursor - Sequencer: Path drop will add either Image or Movie strip - Image window: Path drop will open image ** Drag and drop Notes: - Dropping into another Blender window (from same application) works too. I've added code that passes on mousemoves and clicks to other windows, without activating them though. This does make using multi-window Blender a bit friendler. - Dropping a file path to an image, is not the same as dropping an Image ID... keep this in mind. Sequencer for example wants paths to be dropped, textures in 3d window wants an Image ID. - Although drop boxes could be defined via Python, I suggest they're part of the UI and editor design (= how we want an editor to work), and not default offered configurable like keymaps. - At the moment only one item can be dragged at a time. This is for several reasons.... For one, Blender doesn't have a well defined uniform way to define "what is selected" (files, outliner items, etc). Secondly there's potential conflicts on what todo when you drop mixed drag sets on spots. All undefined stuff... nice for later. - Example to bypass the above: a collection of images that form a strip, should be represented in filewindow as a single sequence anyway. This then will fit well and gets handled neatly by design. - Another option to check is to allow multiple options per drop... it could show the operator as a sort of menu, allowing arrow or scrollwheel to choose. For time being I'd prefer to try to design a singular drop though, just offer only one drop action per data type on given spots. - What does work already, but a tad slow, is to use a function that detects an object (type) under cursor, so a drag item's option can be further refined (like drop object on object = parent). (disabled) ** More notes - Added saving for Region layouts (like split points for toolbar) - Label buttons now handle mouse over - File list: added full path entry for drop feature. - Filesel bugfix: wm_operator_exec() got called there and fully handled, while WM event code tried same. Added new OPERATOR_HANDLED flag for this. Maybe python needs it too? - Cocoa: added window move event, so multi-win setups work OK (didnt save). - Interface_handlers.c: removed win->active - Severe area copy bug: area handlers were not set to NULL - Filesel bugfix: next/prev folder list was not copied on area copies ** Leftover todos - Cocoa windows seem to hang on cases still... needs check - Cocoa 'draw overlap' swap doesn't work - Cocoa window loses focus permanently on using Spotlight (for these reasons, makefile building has Carbon as default atm) - ListView templates in UI cannot become dragged yet, needs review... it consists of two overlapping UI elements, preventing handling icon clicks. - There's already Ghost library code to handle dropping from OS into Blender window. I've noticed this code is unfinished for Macs, but seems to be complete for Windows. Needs test... currently, an external drop event will print in console when succesfully delivered to Blender's WM.
2010-01-26 19:18:21 +01:00
/* when new region opens (region prefsizex/y are zero then */
int prefsizex, prefsizey;
/* default keymaps to add */
int keymapflag;
/* return without drawing.
* lock is set by region definition, and copied to do_lock by render. can become flag. */
short do_lock, lock;
/** Don't handle gizmos events behind #uiBlock's with #UI_BLOCK_CLIP_EVENTS flag set. */
bool clip_gizmo_events_by_ui;
/* call cursor function on each move event */
short event_cursor;
};
/* panel types */
struct PanelType {
PanelType *next, *prev;
char idname[BKE_ST_MAXNAME]; /* unique name */
char label[BKE_ST_MAXNAME]; /* for panel header */
const char *description; /* for panel tooltip */
char translation_context[BKE_ST_MAXNAME];
char context[BKE_ST_MAXNAME]; /* for buttons window */
char category[BKE_ST_MAXNAME]; /* for category tabs */
char owner_id[BKE_ST_MAXNAME]; /* for work-spaces to selectively show. */
2020-06-25 15:13:02 +02:00
char parent_id[BKE_ST_MAXNAME]; /* parent idname for sub-panels */
/** Boolean property identifier of the panel custom data. Used to draw a highlighted border. */
char active_property[BKE_ST_MAXNAME];
short space_type;
short region_type;
/* For popovers, 0 for default. */
int ui_units_x;
int order;
int flag;
/* verify if the panel should draw or not */
bool (*poll)(const bContext *C, PanelType *pt);
/* draw header (optional) */
void (*draw_header)(const bContext *C, Panel *panel);
/* draw header preset (optional) */
void (*draw_header_preset)(const bContext *C, Panel *panel);
/* draw entirely, view changes should be handled here */
void (*draw)(const bContext *C, Panel *panel);
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
/* For instanced panels corresponding to a list: */
/** Reorder function, called when drag and drop finishes. */
void (*reorder)(bContext *C, Panel *pa, int new_index);
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
/**
* Get the panel and sub-panel's expansion state from the expansion flag in the corresponding
* data item. Called on draw updates.
* \note Sub-panels are indexed in depth first order,
* the visual order you would see if all panels were expanded.
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
*/
short (*get_list_data_expand_flag)(const bContext *C, Panel *pa);
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
/**
* Set the expansion bit-field from the closed / open state of this panel and its sub-panels.
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
* Called when the expansion state of the panel changes with user input.
* \note Sub-panels are indexed in depth first order,
* the visual order you would see if all panels were expanded.
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
*/
void (*set_list_data_expand_flag)(const bContext *C, Panel *pa, short expand_flag);
UI: List Panel System This implements a general system to implement drag and drop, subpanels, and UI animation for the stack UIs in Blender. There are NO functional changes in this patch, but it makes it relatively trivial to implement these features for stacks. The biggest complication to using panels to implement the UI for lists is that there can be multiple modifiers of the same type. Currently there is an assumed 1 to 1 relationship between every panel and its type, but there can be multiple list items of the same type, so we have to break this relationship. The mapping between panels and their data is stored with an index in the panel's runtime struct. To make use the system for a list like modifiers, four components must be added: 1. A panel type defined and registered for each list data type, with a known mapping between list data types and panel idnames. 1. A function called by interface code to build the add the panel layouts with the provided helper functions. - UI_panel_list_matches_data will check if the panel list needs to be rebuilt. - UI_panels_free_instanced will remove the existing list panels - UI_panel_add_instanced adds a list panel of a given type. 3. An expand flag for the list data and implementations of get_list_data_expand_flag and set_list_data_expand_flag. 4. For reordering, the panel type's reorder callback. This is called when the instanced panels are drag-dropped. This requires implementing a "move to index" operator for the list data. Reviewed By: Severin, brecht Differential Revision: https://developer.blender.org/D7490
2020-05-26 21:39:49 +02:00
/* sub panels */
PanelType *parent;
ListBase children;
/* RNA integration */
ExtensionRNA rna_ext;
};
/* #PanelType.flag */
enum {
PANEL_TYPE_DEFAULT_CLOSED = (1 << 0),
PANEL_TYPE_NO_HEADER = (1 << 1),
/** Makes buttons in the header shrink/stretch to fill full layout width. */
PANEL_TYPE_HEADER_EXPAND = (1 << 2),
PANEL_TYPE_LAYOUT_VERT_BAR = (1 << 3),
/** This panel type represents data external to the UI. */
PANEL_TYPE_INSTANCED = (1 << 4),
2020-11-17 16:17:00 +01:00
/** Don't search panels with this type during property search. */
PANEL_TYPE_NO_SEARCH = (1 << 7),
};
2023-09-26 11:50:04 +02:00
/* #uiList types. */
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 10:20:16 +01:00
2023-09-26 11:50:04 +02:00
/** Draw an item in the `ui_list`. */
using uiListDrawItemFunc = void (*)(uiList *ui_list,
const bContext *C,
uiLayout *layout,
PointerRNA *dataptr,
PointerRNA *itemptr,
int icon,
PointerRNA *active_dataptr,
const char *active_propname,
int index,
int flt_flag);
/* Draw the filtering part of an uiList */
using uiListDrawFilterFunc = void (*)(uiList *ui_list, const bContext *C, uiLayout *layout);
/* Filter items of an uiList */
using uiListFilterItemsFunc = void (*)(uiList *ui_list,
const bContext *C,
PointerRNA *,
const char *propname);
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 10:20:16 +01:00
UI/Assets: Initial Asset View UI template The asset view UI template is a mini-version of the Asset Browser that can be placed in regular layouts, regions or popups. At this point it's made specifically for placement in vertical layouts, it can be made more flexible in the future. Generally the way this is implemented will likely change a lot still as the asset system evolves. The Pose Library add-on will use the asset view to display pose libraries in the 3D View sidebar. References: * https://developer.blender.org/T86139 * https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building * https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport Notes: * Important limitation: Due to the early & WIP implementation of the asset list, all asset views showing the same library will show the same assets. That is despite the ID type filter option the template provides. The first asset view created will determine what's visible. Of course this should be made to work eventually. * The template supports passing an activate and a drag operator name. The former is called when an asset is clicked on (e.g. to apply the asset) the latter when dragging (e.g. to .blend a pose asset). If no drag operator is set, regular asset drag & drop will be executed. * The template returns the properties for both operators (see example below). * The argument list for using the template is quite long, but we can't avoid that currently. The UI list design requires that we pass a number of RNA or custom properties to work with, that for the Pose Libraries should be registered at the Pose Library add-on level, not in core Blender. * Idea is that Python scripts or add-ons that want to use the asset view can register custom properties, to hold data like the list of assets, and the active asset index. Maybe that will change in future and we can manage these internally. As an example, the pose library add-on uses it like this: ``` activate_op_props, drag_op_props = layout.template_asset_view( "pose_assets", workspace, "active_asset_library", wm, "pose_assets", workspace, "active_pose_asset_index", filter_id_types={"filter_action"}, activate_operator="poselib.apply_pose_asset", drag_operator="poselib.blend_pose_asset", ) drag_op_props.release_confirm = True drag_op_props.flipped = wm.poselib_flipped activate_op_props.flipped = wm.poselib_flipped ```
2021-07-13 18:07:57 +02:00
/* Listen to notifiers. Only for lists defined in C. */
using uiListListener = void (*)(uiList *ui_list, wmRegionListenerParams *params);
UI/Assets: Initial Asset View UI template The asset view UI template is a mini-version of the Asset Browser that can be placed in regular layouts, regions or popups. At this point it's made specifically for placement in vertical layouts, it can be made more flexible in the future. Generally the way this is implemented will likely change a lot still as the asset system evolves. The Pose Library add-on will use the asset view to display pose libraries in the 3D View sidebar. References: * https://developer.blender.org/T86139 * https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building * https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport Notes: * Important limitation: Due to the early & WIP implementation of the asset list, all asset views showing the same library will show the same assets. That is despite the ID type filter option the template provides. The first asset view created will determine what's visible. Of course this should be made to work eventually. * The template supports passing an activate and a drag operator name. The former is called when an asset is clicked on (e.g. to apply the asset) the latter when dragging (e.g. to .blend a pose asset). If no drag operator is set, regular asset drag & drop will be executed. * The template returns the properties for both operators (see example below). * The argument list for using the template is quite long, but we can't avoid that currently. The UI list design requires that we pass a number of RNA or custom properties to work with, that for the Pose Libraries should be registered at the Pose Library add-on level, not in core Blender. * Idea is that Python scripts or add-ons that want to use the asset view can register custom properties, to hold data like the list of assets, and the active asset index. Maybe that will change in future and we can manage these internally. As an example, the pose library add-on uses it like this: ``` activate_op_props, drag_op_props = layout.template_asset_view( "pose_assets", workspace, "active_asset_library", wm, "pose_assets", workspace, "active_pose_asset_index", filter_id_types={"filter_action"}, activate_operator="poselib.apply_pose_asset", drag_operator="poselib.blend_pose_asset", ) drag_op_props.release_confirm = True drag_op_props.flipped = wm.poselib_flipped activate_op_props.flipped = wm.poselib_flipped ```
2021-07-13 18:07:57 +02:00
struct uiListType {
uiListType *next, *prev;
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 10:20:16 +01:00
char idname[BKE_ST_MAXNAME]; /* unique name */
uiListDrawItemFunc draw_item;
uiListDrawFilterFunc draw_filter;
uiListFilterItemsFunc filter_items;
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 10:20:16 +01:00
UI/Assets: Initial Asset View UI template The asset view UI template is a mini-version of the Asset Browser that can be placed in regular layouts, regions or popups. At this point it's made specifically for placement in vertical layouts, it can be made more flexible in the future. Generally the way this is implemented will likely change a lot still as the asset system evolves. The Pose Library add-on will use the asset view to display pose libraries in the 3D View sidebar. References: * https://developer.blender.org/T86139 * https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building * https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport Notes: * Important limitation: Due to the early & WIP implementation of the asset list, all asset views showing the same library will show the same assets. That is despite the ID type filter option the template provides. The first asset view created will determine what's visible. Of course this should be made to work eventually. * The template supports passing an activate and a drag operator name. The former is called when an asset is clicked on (e.g. to apply the asset) the latter when dragging (e.g. to .blend a pose asset). If no drag operator is set, regular asset drag & drop will be executed. * The template returns the properties for both operators (see example below). * The argument list for using the template is quite long, but we can't avoid that currently. The UI list design requires that we pass a number of RNA or custom properties to work with, that for the Pose Libraries should be registered at the Pose Library add-on level, not in core Blender. * Idea is that Python scripts or add-ons that want to use the asset view can register custom properties, to hold data like the list of assets, and the active asset index. Maybe that will change in future and we can manage these internally. As an example, the pose library add-on uses it like this: ``` activate_op_props, drag_op_props = layout.template_asset_view( "pose_assets", workspace, "active_asset_library", wm, "pose_assets", workspace, "active_pose_asset_index", filter_id_types={"filter_action"}, activate_operator="poselib.apply_pose_asset", drag_operator="poselib.blend_pose_asset", ) drag_op_props.release_confirm = True drag_op_props.flipped = wm.poselib_flipped activate_op_props.flipped = wm.poselib_flipped ```
2021-07-13 18:07:57 +02:00
/* For lists defined in C only. */
uiListListener listener;
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 10:20:16 +01:00
/* RNA integration */
ExtensionRNA rna_ext;
};
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 10:20:16 +01:00
/* header types */
struct HeaderType {
HeaderType *next, *prev;
char idname[BKE_ST_MAXNAME]; /* unique name */
int space_type;
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 region_type;
bool (*poll)(const bContext *C, HeaderType *ht);
/* draw entirely, view changes should be handled here */
void (*draw)(const bContext *C, Header *header);
/* RNA integration */
ExtensionRNA rna_ext;
};
struct Header {
HeaderType *type; /* runtime */
uiLayout *layout; /* runtime for drawing */
};
/* menu types */
enum class MenuTypeFlag {
/**
* Whether the menu depends on data retrieved via #CTX_data_pointer_get. If it is context
* dependent, menu search has to scan it in different contexts.
*/
ContextDependent = (1 << 0),
/**
* Automatically start searching in the menu when pressing a key.
*/
SearchOnKeyPress = (1 << 1),
};
ENUM_OPERATORS(MenuTypeFlag, MenuTypeFlag::ContextDependent)
struct MenuType {
MenuType *next, *prev;
char idname[BKE_ST_MAXNAME]; /* unique name */
char label[BKE_ST_MAXNAME]; /* for button text */
char translation_context[BKE_ST_MAXNAME];
char owner_id[BKE_ST_MAXNAME]; /* optional, see: #wmOwnerID */
2014-02-06 21:39:44 +01:00
const char *description;
/* verify if the menu should draw or not */
bool (*poll)(const bContext *C, MenuType *mt);
/* draw entirely, view changes should be handled here */
void (*draw)(const bContext *C, Menu *menu);
void (*listener)(const wmRegionListenerParams *params);
MenuTypeFlag flag;
/* RNA integration */
ExtensionRNA rna_ext;
};
struct Menu {
MenuType *type; /* runtime */
uiLayout *layout; /* runtime for drawing */
};
/* asset shelf types */
/* #AssetShelfType.flag */
enum AssetShelfTypeFlag {
/** Do not trigger asset dragging on drag events. Drag events can be overridden with custom
* keymap items then. */
ASSET_SHELF_TYPE_FLAG_NO_ASSET_DRAG = (1 << 0),
ASSET_SHELF_TYPE_FLAG_MAX
};
ENUM_OPERATORS(AssetShelfTypeFlag, ASSET_SHELF_TYPE_FLAG_MAX);
struct AssetShelfType {
AssetShelfType *next, *prev;
char idname[BKE_ST_MAXNAME]; /* unique name */
int space_type;
AssetShelfTypeFlag flag;
/** Determine if asset shelves of this type should be available in current context or not. */
bool (*poll)(const bContext *C, const AssetShelfType *shelf_type);
/** Determine if an individual asset should be visible or not. May be a temporary design,
* visibility should first and foremost be controlled by asset traits. */
bool (*asset_poll)(const AssetShelfType *shelf_type,
const blender::asset_system::AssetRepresentation *asset);
/** Asset shelves can define their own context menu via this layout definition callback. */
void (*draw_context_menu)(const bContext *C,
const AssetShelfType *shelf_type,
const blender::asset_system::AssetRepresentation *asset,
uiLayout *layout);
/* RNA integration */
ExtensionRNA rna_ext;
};
/* Space-types. */
SpaceType *BKE_spacetype_from_id(int spaceid);
ARegionType *BKE_regiontype_from_id(const SpaceType *st, int regionid);
const ListBase *BKE_spacetypes_list();
void BKE_spacetype_register(SpaceType *st);
bool BKE_spacetype_exists(int spaceid);
void BKE_spacetypes_free(); /* only for quitting blender */
/* Space-data. */
void BKE_spacedata_freelist(ListBase *lb);
/**
* \param lb_dst: should be empty (will be cleared).
*/
void BKE_spacedata_copylist(ListBase *lb_dst, ListBase *lb_src);
/**
* Facility to set locks for drawing to survive (render) threads accessing drawing data.
*
* \note Lock can become bit-flag too.
* \note Should be replaced in future by better local data handling for threads.
*/
2021-02-26 06:50:36 +01:00
void BKE_spacedata_draw_locks(bool set);
/**
* Version of #BKE_area_find_region_type that also works if \a slink
* is not the active space of \a area.
*/
ARegion *BKE_spacedata_find_region_type(const SpaceLink *slink,
const ScrArea *area,
int region_type) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
void BKE_spacedata_callback_id_remap_set(
void (*func)(ScrArea *area, SpaceLink *sl, ID *old_id, ID *new_id));
/**
* Currently unused!
*/
void BKE_spacedata_id_unref(ScrArea *area, SpaceLink *sl, ID *id);
/* Area/regions. */
ARegion *BKE_area_region_copy(const SpaceType *st, const ARegion *region);
/**
* Doesn't free the region itself.
*/
void BKE_area_region_free(SpaceType *st, ARegion *region);
void BKE_area_region_panels_free(ListBase *panels);
/**
* Doesn't free the area itself.
*/
void BKE_screen_area_free(ScrArea *area);
/**
* Gizmo-maps of a region need to be freed with the region.
* Uses callback to avoid low-level call.
*/
void BKE_region_callback_free_gizmomap_set(void (*callback)(wmGizmoMap *));
void BKE_region_callback_refresh_tag_gizmomap_set(void (*callback)(wmGizmoMap *));
/**
* Find a region of type \a region_type in provided \a regionbase.
*
* \note this is useful for versioning where either the #Area or #SpaceLink regionbase are typical
* inputs
*/
ARegion *BKE_region_find_in_listbase_by_type(const ListBase *regionbase, const int region_type);
/**
* Find a region of type \a region_type in the currently active space of \a area.
*
* \note This does _not_ work if the region to look up is not in the active space.
* Use #BKE_spacedata_find_region_type if that may be the case.
*/
ARegion *BKE_area_find_region_type(const ScrArea *area, int type);
ARegion *BKE_area_find_region_active_win(const ScrArea *area);
ARegion *BKE_area_find_region_xy(const ScrArea *area, int regiontype, const int xy[2])
ATTR_NONNULL(3);
/**
* \note This is only for screen level regions (typically menus/popups).
*/
ARegion *BKE_screen_find_region_xy(const bScreen *screen,
int regiontype,
const int xy[2]) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL(1, 3);
ARegion *BKE_screen_find_main_region_at_xy(const bScreen *screen, int space_type, const int xy[2])
ATTR_NONNULL(1, 3);
/**
* \note Ideally we can get the area from the context,
* there are a few places however where this isn't practical.
*/
ScrArea *BKE_screen_find_area_from_space(const bScreen *screen,
const SpaceLink *sl) ATTR_WARN_UNUSED_RESULT
ATTR_NONNULL(1, 2);
/**
* \note Using this function is generally a last resort, you really want to be
* using the context when you can - campbell
*/
ScrArea *BKE_screen_find_big_area(const bScreen *screen, int spacetype, short min);
ScrArea *BKE_screen_area_map_find_area_xy(const ScrAreaMap *areamap,
int spacetype,
const int xy[2]) ATTR_NONNULL(1, 3);
ScrArea *BKE_screen_find_area_xy(const bScreen *screen, int spacetype, const int xy[2])
ATTR_NONNULL(1, 3);
void BKE_screen_gizmo_tag_refresh(bScreen *screen);
void BKE_screen_view3d_sync(View3D *v3d, Scene *scene);
void BKE_screen_view3d_scene_sync(bScreen *screen, Scene *scene);
bool BKE_screen_is_fullscreen_area(const bScreen *screen) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
bool BKE_screen_is_used(const bScreen *screen) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
/* Zoom factor conversion. */
float BKE_screen_view3d_zoom_to_fac(float camzoom);
float BKE_screen_view3d_zoom_from_fac(float zoomfac);
void BKE_screen_view3d_shading_init(View3DShading *shading);
/* Screen. */
/**
* Callback used by lib_query to walk over all ID usages
* (mimics `foreach_id` callback of #IDTypeInfo structure).
*/
void BKE_screen_foreach_id_screen_area(LibraryForeachIDData *data, ScrArea *area);
/**
* Free (or release) any data used by this screen (does not free the screen itself).
*/
void BKE_screen_free_data(bScreen *screen);
void BKE_screen_area_map_free(ScrAreaMap *area_map) ATTR_NONNULL();
ScrEdge *BKE_screen_find_edge(const bScreen *screen, ScrVert *v1, ScrVert *v2);
void BKE_screen_sort_scrvert(ScrVert **v1, ScrVert **v2);
void BKE_screen_remove_double_scrverts(bScreen *screen);
void BKE_screen_remove_double_scredges(bScreen *screen);
void BKE_screen_remove_unused_scredges(bScreen *screen);
void BKE_screen_remove_unused_scrverts(bScreen *screen);
void BKE_screen_header_alignment_reset(bScreen *screen);
/* .blend file I/O */
void BKE_screen_view3d_shading_blend_write(BlendWriter *writer, View3DShading *shading);
void BKE_screen_view3d_shading_blend_read_data(BlendDataReader *reader, View3DShading *shading);
void BKE_screen_area_map_blend_write(BlendWriter *writer, ScrAreaMap *area_map);
/**
* \return false on error.
*/
bool BKE_screen_area_map_blend_read_data(BlendDataReader *reader, ScrAreaMap *area_map);
/**
* And as patch for 2.48 and older.
* For the saved 2.50 files without `regiondata`.
*/
void BKE_screen_view3d_do_versions_250(View3D *v3d, ListBase *regions);
/**
* Called after lib linking process is done, to perform some validation on the read data, or some
* complex specific reading process that requires the data to be fully read and ID pointers to be
* valid.
*/
void BKE_screen_area_blend_read_after_liblink(BlendLibReader *reader,
ID *parent_id,
ScrArea *area);
/**
* Cannot use #IDTypeInfo callback yet, because of the return value.
*/
bool BKE_screen_blend_read_data(BlendDataReader *reader, bScreen *screen);