archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
51da664fa1848b086b3a942c37dddd8cce0b0d89
blender-archive/source/blender/editors/space_outliner/outliner_draw.c

1986 lines
63 KiB
C
Raw Normal View History

== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +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
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2004 Blender Foundation.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): Joshua Leung
*
* ***** END GPL LICENSE BLOCK *****
*/
/** \file blender/editors/space_outliner/outliner_draw.c
* \ingroup spoutliner
*/
Fix T42163: Outliner: recursive visibility toggle: autokeyframe only works for ancestor, not children Ancestor's autokeyframing is handled through UI/buttons code, but children completely skipped this, so we have to do it explicitely here...
2014-10-10 15:04:33 +02:00
#include "DNA_anim_types.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "DNA_armature_types.h"
GPencil: Initial support for GP Layers in Outliner This is still very rudimentary, and lacks many things. * This needs a better icon. Perhaps we can look into using colour swatches here too like in all the other places? * The "active" check needs to be implemented still * Various restriction toggles to come still
2015-02-07 12:50:22 +13:00
#include "DNA_gpencil_types.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "DNA_group_types.h"
#include "DNA_lamp_types.h"
outliner header cleanup (copy pasted headers when split up Im guessing)
2012-04-26 05:17:54 +00:00
#include "DNA_object_types.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "DNA_scene_types.h"
#include "DNA_sequence_types.h"
use min/max inline functions where MIN2/MAX2 were doing type conversion.
2012-10-27 11:18:54 +00:00
#include "BLI_math.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "BLI_blenlib.h"
Cleanup/refactor: Add new BLI_string_util. Things like `BLI_uniquename` had nothing, but really nothing to do in BLI_path_util files! Also, got rid of length limitation in `BLI_uniquename_cb`, we can use alloca here to avoid overhead of malloc while keeping free size (within reasonable limits of course).
2017-01-16 17:33:34 +01:00
#include "BLI_string_utils.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "BLI_utildefines.h"
fix for [#36260] 2,300 Objects Makes Blender Unresponsive - performance of outliner was low because of unoptimal data structures. - now it uses BLI_mempool instead of custom mempool and GHash to make searches for duplicates faster. - also fix undesired behaviour of BLI_mempool_as_arrayN thanks to Campbell Barton and Lukas Tönne for helping me get a better fix put together.
2013-08-03 11:35:09 +00:00
#include "BLI_mempool.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
#include "BLT_translation.h"
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "BKE_context.h"
#include "BKE_deform.h"
Fix T42163: Outliner: recursive visibility toggle: autokeyframe only works for ancestor, not children Ancestor's autokeyframing is handled through UI/buttons code, but children completely skipped this, so we have to do it explicitely here...
2014-10-10 15:04:33 +02:00
#include "BKE_fcurve.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "BKE_global.h"
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
#include "BKE_layer.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "BKE_library.h"
#include "BKE_main.h"
#include "BKE_modifier.h"
#include "BKE_report.h"
#include "BKE_scene.h"
Added Recursive select/deselect to outliner (CTRL+LMB)
2013-03-09 07:17:35 +00:00
#include "BKE_object.h"
use ghash for operator and menu types, was doing string lookup in the operator list (containing over 1000 items) for each button draw. gives small speedup for UI drawing and overall startup time.
2011-08-11 06:06:17 +00:00
Replace all old DAG calls with direct calls to new DEG and remove BKE_depsgraph.h This removes BKE_depsgraph.h and depsgraph.c
2017-06-08 10:14:53 +02:00
#include "DEG_depsgraph.h"
Layer collection enable flag Right now this is exposed in the outliner, though all this (visible/selectable/enable) should be moved to a new panel soon. This removes objects from the depsgraph when the collection is disabled. It allows you to "hide" lamps but still having them lighting the scene. Same for light probes and other support objects. Pending tasks: * Have depsgraph to include invisible objects in the DEG_OBJECTS_ITER, and then have Eevee and other engines to make a distinction between an invisible and a visible object. (for example, we probably want invisible objects to not show in the viewport, but cast shadows and show up in light probes). * Change how we evaluate collection settings so that an invisible collection can force an object to be invisible. Reviewers: campbellbarton Subscribers: sergey Differential Revision: https://developer.blender.org/D2848
2017-09-20 14:15:35 +02:00
#include "DEG_depsgraph_build.h"
Replace all old DAG calls with direct calls to new DEG and remove BKE_depsgraph.h This removes BKE_depsgraph.h and depsgraph.c
2017-06-08 10:14:53 +02:00
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "ED_armature.h"
Fix T42163: Outliner: recursive visibility toggle: autokeyframe only works for ancestor, not children Ancestor's autokeyframing is handled through UI/buttons code, but children completely skipped this, so we have to do it explicitely here...
2014-10-10 15:04:33 +02:00
#include "ED_keyframing.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "ED_object.h"
#include "ED_screen.h"
#include "WM_api.h"
#include "WM_types.h"
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
#include "GPU_immediate.h"
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
#include "UI_interface.h"
#include "UI_interface_icons.h"
#include "UI_resources.h"
#include "UI_view2d.h"
#include "RNA_access.h"
#include "outliner_intern.h"
disable group/object selection in the outliner, it slows down drawing far too much.
2012-06-06 19:36:26 +00:00
/* disable - this is far too slow - campbell */
// #define USE_GROUP_SELECT
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* ****************************************************** */
/* Tree Size Functions */
static void outliner_height(SpaceOops *soops, ListBase *lb, int *h)
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeElement *te = lb->first;
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
while (te) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeStoreElem *tselem = TREESTORE(te);
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops))
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
outliner_height(soops, &te->subtree, h);
(*h) += UI_UNIT_Y;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
te = te->next;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
#if 0 // XXX this is currently disabled until te->xend is set correctly
static void outliner_width(SpaceOops *soops, ListBase *lb, int *w)
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeElement *te = lb->first;
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
while (te) {
style cleanup
2012-10-26 04:14:10 +00:00
// TreeStoreElem *tselem = TREESTORE(te);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
// XXX fixme... te->xend is not set yet
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (!TSELEM_OPEN(tselem, soops)) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
if (te->xend > *w)
*w = te->xend;
}
outliner_width(soops, &te->subtree, w);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
te = te->next;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
#endif
static void outliner_rna_width(SpaceOops *soops, ListBase *lb, int *w, int startx)
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeElement *te = lb->first;
style cleanup: follow style guide for/with/if spacing
2012-03-24 07:52:14 +00:00
while (te) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeStoreElem *tselem = TREESTORE(te);
style cleanup - use aligned * prefixed blocks for descriptive comments (was already used a lot and part of proposed style guide).
2012-03-03 16:31:46 +00:00
// XXX fixme... (currently, we're using a fixed length of 100)!
#if 0
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (te->xend) {
if (te->xend > *w)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
*w = te->xend;
style cleanup - use aligned * prefixed blocks for descriptive comments (was already used a lot and part of proposed style guide).
2012-03-03 16:31:46 +00:00
}
#endif
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (startx + 100 > *w)
*w = startx + 100;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops))
style cleanup: outliner
2012-05-07 17:56:30 +00:00
outliner_rna_width(soops, &te->subtree, w, startx + UI_UNIT_X);
te = te->next;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
/* ****************************************************** */
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
static void restrictbutton_recursive_ebone(bContext *C, EditBone *ebone_parent, int flag, bool set_flag)
{
Object *obedit = CTX_data_edit_object(C);
bArmature *arm = obedit->data;
EditBone *ebone;
for (ebone = arm->edbo->first; ebone; ebone = ebone->next) {
if (ED_armature_ebone_is_child_recursive(ebone_parent, ebone)) {
if (set_flag) {
ebone->flag &= ~(BONE_TIPSEL | BONE_SELECTED | BONE_ROOTSEL);
ebone->flag |= flag;
}
else {
fix for 2 errors where the 2d arrays were used as 3d. (out of bounds read). also minor code cleanup.
2013-03-13 18:10:05 +00:00
ebone->flag &= ~flag;
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
}
}
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void restrictbutton_recursive_bone(Bone *bone_parent, int flag, bool set_flag)
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
{
Bone *bone;
for (bone = bone_parent->childbase.first; bone; bone = bone->next) {
if (set_flag) {
bone->flag &= ~(BONE_TIPSEL | BONE_SELECTED | BONE_ROOTSEL);
bone->flag |= flag;
}
else {
fix for 2 errors where the 2d arrays were used as 3d. (out of bounds read). also minor code cleanup.
2013-03-13 18:10:05 +00:00
bone->flag &= ~flag;
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
restrictbutton_recursive_bone(bone, flag, set_flag);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
static void restrictbutton_r_lay_cb(bContext *C, void *poin, void *UNUSED(poin2))
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_SCENE | ND_RENDER_OPTIONS, poin);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
static void restrictbutton_modifier_cb(bContext *C, void *UNUSED(poin), void *poin2)
{
Object *ob = (Object *)poin2;
Replace all old DAG calls with direct calls to new DEG and remove BKE_depsgraph.h This removes BKE_depsgraph.h and depsgraph.c
2017-06-08 10:14:53 +02:00
DEG_id_tag_update(&ob->id, OB_RECALC_DATA);
Fix T44162: Outliner: modifier's icons toggle update issue Use same notifier for button callback as the one used in matching outliner operator...
2015-03-29 13:14:59 +02:00
WM_event_add_notifier(C, NC_OBJECT | ND_MODIFIER, ob);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void restrictbutton_bone_visibility_cb(bContext *C, void *UNUSED(poin), void *poin2)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Bone *bone = (Bone *)poin2;
code cleanup: remove redundant NULL checks
2013-07-31 09:18:40 +00:00
if (bone->flag & BONE_HIDDEN_P)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
bone->flag &= ~(BONE_SELECTED | BONE_TIPSEL | BONE_ROOTSEL);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
if (CTX_wm_window(C)->eventstate->ctrl) {
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
restrictbutton_recursive_bone(bone, BONE_HIDDEN_P, (bone->flag & BONE_HIDDEN_P) != 0);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, NULL);
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void restrictbutton_bone_select_cb(bContext *C, void *UNUSED(poin), void *poin2)
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
{
Bone *bone = (Bone *)poin2;
code cleanup: remove redundant NULL checks
2013-07-31 09:18:40 +00:00
if (bone->flag & BONE_UNSELECTABLE)
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
bone->flag &= ~(BONE_SELECTED | BONE_TIPSEL | BONE_ROOTSEL);
if (CTX_wm_window(C)->eventstate->ctrl) {
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
restrictbutton_recursive_bone(bone, BONE_UNSELECTABLE, (bone->flag & BONE_UNSELECTABLE) != 0);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, NULL);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Fix for strict compiler's flags
2013-03-12 14:06:18 +00:00
static void restrictbutton_ebone_select_cb(bContext *C, void *UNUSED(poin), void *poin2)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
EditBone *ebone = (EditBone *)poin2;
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
if (ebone->flag & BONE_UNSELECTABLE) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
ebone->flag &= ~(BONE_SELECTED | BONE_TIPSEL | BONE_ROOTSEL);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
if (CTX_wm_window(C)->eventstate->ctrl) {
restrictbutton_recursive_ebone(C, ebone, BONE_UNSELECTABLE, (ebone->flag & BONE_UNSELECTABLE) != 0);
}
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, NULL);
}
Fix for strict compiler's flags
2013-03-12 14:06:18 +00:00
static void restrictbutton_ebone_visibility_cb(bContext *C, void *UNUSED(poin), void *poin2)
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
{
EditBone *ebone = (EditBone *)poin2;
if (ebone->flag & BONE_HIDDEN_A) {
style cleanup
2013-03-12 21:46:33 +00:00
ebone->flag &= ~(BONE_SELECTED | BONE_TIPSEL | BONE_ROOTSEL);
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
}
if (CTX_wm_window(C)->eventstate->ctrl) {
restrictbutton_recursive_ebone(C, ebone, BONE_HIDDEN_A, (ebone->flag & BONE_HIDDEN_A) != 0);
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, NULL);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
GPencil: Viewport visbility and editability toggles for layers in Outliner * Viewport visibility and locking are currently exposed * Later on, visibility in renders can also be included
2015-02-09 12:34:17 +13:00
static void restrictbutton_gp_layer_flag_cb(bContext *C, void *UNUSED(poin), void *UNUSED(poin2))
{
Fix T43669: Grease Pencil visibility toggle not working in Outliner
2015-02-17 02:08:12 +01:00
WM_event_add_notifier(C, NC_GPENCIL | ND_DATA | NA_EDITED, NULL);
GPencil: Viewport visbility and editability toggles for layers in Outliner * Viewport visibility and locking are currently exposed * Later on, visibility in renders can also be included
2015-02-09 12:34:17 +13:00
}
Tag depsgraph update when hide and hide_select are changed We were not updating depsgraph when collection just "became" selectable, but although this doesn't change object selection, it change its selectability.
2017-04-21 14:31:38 +02:00
static void restrictbutton_collection_flag_cb(bContext *C, void *poin, void *UNUSED(poin2))
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
{
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
ID *id = (ID *)poin;
Blender 2.8: Hook of layer collections evaluation in DEG This moves selectability/visibility flag flush from some hardcoded places in the code to depsgraph. This way it is possible to simply tag depsgraph to update those flags and rest it'll do on its own. Using depsgraph for such flush is an overkill: those flags are fully static and can not be animated, so it doesn't really make sense to hook only those to depsgraph. However, in the future we will have overrides on collections, which ideally would need to be animatable and drivable and easiest way to support this is to do this on depsgraph level, so it ensures proper order of evaluation for animation and drivers. And it seems logical to do both overrides and flags flush from depsgraph from this point of view. This commit also includes the evaluation of IDProperty for collections, which basically are just another form of override. So once we implement the other kind of overrides the flushing and collection evaluation won't change. Patch by Sergey Sharybin and Dalai Felinto
2017-03-17 12:47:29 +01:00
/* TODO(sergey): Use proper flag for tagging here. */
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
DEG_id_tag_update(id, 0);
if (GS(id->name) == ID_SCE) {
WM_event_add_notifier(C, NC_SCENE | ND_OB_SELECT, id);
}
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
WM_event_add_notifier(C, NC_SCENE | ND_LAYER_CONTENT, NULL);
}
Compilation error fix for strict compiler flags
2015-02-15 23:12:54 +05:00
static void restrictbutton_id_user_toggle(bContext *UNUSED(C), void *poin, void *UNUSED(poin2))
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
{
ID *id = (ID *)poin;
BLI_assert(id != NULL);
if (id->flag & LIB_FAKEUSER) {
id_us_plus(id);
}
else {
id_us_min(id);
}
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
static void namebutton_cb(bContext *C, void *tsep, char *oldname)
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
SpaceOops *soops = CTX_wm_space_outliner(C);
Scene *scene = CTX_data_scene(C);
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
ViewLayer *view_layer = CTX_data_view_layer(C);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Object *obedit = CTX_data_edit_object(C);
fix for [#36260] 2,300 Objects Makes Blender Unresponsive - performance of outliner was low because of unoptimal data structures. - now it uses BLI_mempool instead of custom mempool and GHash to make searches for duplicates faster. - also fix undesired behaviour of BLI_mempool_as_arrayN thanks to Campbell Barton and Lukas Tönne for helping me get a better fix put together.
2013-08-03 11:35:09 +00:00
BLI_mempool *ts = soops->treestore;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
TreeStoreElem *tselem = tsep;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (ts && tselem) {
Fix outliner crash renaming library /w filter D1045 by @a.romanov
2015-02-10 02:03:55 +11:00
TreeElement *te = outliner_find_tree_element(&soops->tree, tselem);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (tselem->type == 0) {
Cleanup: use BLI_libblock prefix for id functions - test_idbutton -> BLI_libblock_ensure_unique_name (not only used from UI) - BKE_rename_id -> BKE_libblock_rename (always pass valid main) also rename: - name_uiprefix_id -> BKE_id_uiprefix
2015-12-28 17:17:25 +11:00
BLI_libblock_ensure_unique_name(G.main, tselem->id->name);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (GS(tselem->id->name)) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case ID_MA:
WM_event_add_notifier(C, NC_MATERIAL, NULL); break;
case ID_TE:
WM_event_add_notifier(C, NC_TEXTURE, NULL); break;
case ID_IM:
WM_event_add_notifier(C, NC_IMAGE, NULL); break;
case ID_SCE:
WM_event_add_notifier(C, NC_SCENE, NULL); break;
default:
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_ID | NA_RENAME, NULL); break;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* Check the library target exists */
if (te->idcode == ID_LI) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Library *lib = (Library *)tselem->id;
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
char expanded[FILE_MAX];
Support more kinds of paths for path re-writing / traversing, patch from Alex Fraser with additions. this now supports as many types as bpath iterator which its intended to replace.
2011-10-26 22:46:06 +00:00
BKE_library_filepath_set(lib, lib->name);
remove $Id: tags after discussion on the mailign list: http://markmail.org/message/fp7ozcywxum3ar7n
2011-10-23 17:52:20 +00:00
Support more kinds of paths for path re-writing / traversing, patch from Alex Fraser with additions. this now supports as many types as bpath iterator which its intended to replace.
2011-10-26 22:46:06 +00:00
BLI_strncpy(expanded, lib->name, sizeof(expanded));
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
BLI_path_abs(expanded, G.main->name);
if (!BLI_exists(expanded)) {
style cleanup
2012-05-31 18:40:06 +00:00
BKE_reportf(CTX_wm_reports(C), RPT_ERROR,
"Library path '%s' does not exist, correct this before saving", expanded);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
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
else if (lib->id.tag & LIB_TAG_MISSING) {
BKE_reportf(CTX_wm_reports(C), RPT_INFO,
"Library path '%s' is now valid, please reload the library", expanded);
lib->id.tag &= ~LIB_TAG_MISSING;
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
else {
style cleanup: changes to brace placement / newlines - for/while/if/switch
2012-04-28 06:31:57 +00:00
switch (tselem->type) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
case TSE_DEFGROUP:
defgroup_unique_name(te->directdata, (Object *)tselem->id); // id = object
break;
case TSE_NLA_ACTION:
Cleanup: use BLI_libblock prefix for id functions - test_idbutton -> BLI_libblock_ensure_unique_name (not only used from UI) - BKE_rename_id -> BKE_libblock_rename (always pass valid main) also rename: - name_uiprefix_id -> BKE_id_uiprefix
2015-12-28 17:17:25 +11:00
BLI_libblock_ensure_unique_name(G.main, tselem->id->name);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
break;
case TSE_EBONE:
{
bArmature *arm = (bArmature *)tselem->id;
if (arm->edbo) {
EditBone *ebone = te->directdata;
char newname[sizeof(ebone->name)];
/* restore bone name */
BLI_strncpy(newname, ebone->name, sizeof(ebone->name));
BLI_strncpy(ebone->name, oldname, sizeof(ebone->name));
ED_armature_bone_rename(obedit->data, oldname, newname);
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, OBACT(view_layer));
style cleanup: outliner
2012-05-07 17:56:30 +00:00
}
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
case TSE_BONE:
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Bone *bone = te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Object *ob;
char newname[sizeof(bone->name)];
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
/* always make current object active */
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
tree_element_active(C, scene, view_layer, soops, te, OL_SETSEL_NORMAL, true);
ob = OBACT(view_layer);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* restore bone name */
BLI_strncpy(newname, bone->name, sizeof(bone->name));
BLI_strncpy(bone->name, oldname, sizeof(bone->name));
ED_armature_bone_rename(ob->data, oldname, newname);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, ob);
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
case TSE_POSE_CHANNEL:
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
bPoseChannel *pchan = te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Object *ob;
char newname[sizeof(pchan->name)];
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
/* always make current pose-bone active */
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
tree_element_active(C, scene, view_layer, soops, te, OL_SETSEL_NORMAL, true);
ob = OBACT(view_layer);
Fix T39383: Blender crash when renaming bone in outliner (weight paint mode). Outliner rename callback is supposed to activate affected element before actually renaming, but for bones this was not working because the function used to activate the object explicitely ignored ID_OB case! Added a bool flag to allow handing this case without (possibly) breaking the other usecases.
2014-03-24 13:08:29 +01:00
BLI_assert(ob->type == OB_ARMATURE);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* restore bone name */
BLI_strncpy(newname, pchan->name, sizeof(pchan->name));
BLI_strncpy(pchan->name, oldname, sizeof(pchan->name));
ED_armature_bone_rename(ob->data, oldname, newname);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, ob);
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
case TSE_POSEGRP:
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Object *ob = (Object *)tselem->id; // id = object
bActionGroup *grp = te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Refactor translation code out of blenfont - Add blentranslation `BLT_*` module. - moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`). - moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
2015-08-16 17:32:01 +10:00
BLI_uniquename(&ob->pose->agroups, grp, CTX_DATA_(BLT_I18NCONTEXT_ID_ACTION, "Group"), '.',
More new data names translation (most cases should be covered now). Also done a few cleanup here and there...
2013-03-25 08:29:06 +00:00
offsetof(bActionGroup, name), sizeof(grp->name));
style cleanup: outliner
2012-05-07 17:56:30 +00:00
WM_event_add_notifier(C, NC_OBJECT | ND_POSE, ob);
style cleanup: switch statements, include break statements within braces & indent. also indent case's within the switch (we already did both of these almost everywhere)
2013-07-19 15:23:42 +00:00
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
GPencil: Initial support for GP Layers in Outliner This is still very rudimentary, and lacks many things. * This needs a better icon. Perhaps we can look into using colour swatches here too like in all the other places? * The "active" check needs to be implemented still * Various restriction toggles to come still
2015-02-07 12:50:22 +13:00
case TSE_GP_LAYER:
{
bGPdata *gpd = (bGPdata *)tselem->id; // id = GP Datablock
bGPDlayer *gpl = te->directdata;
// XXX: name needs translation stuff
BLI_uniquename(&gpd->layers, gpl, "GP Layer", '.',
offsetof(bGPDlayer, info), sizeof(gpl->info));
WM_event_add_notifier(C, NC_GPENCIL | ND_DATA, gpd);
break;
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
case TSE_R_LAYER:
break;
Outliner: Make sure collection name is unique after renaming
2017-03-01 16:32:13 +01:00
case TSE_SCENE_COLLECTION:
case TSE_LAYER_COLLECTION:
{
SceneCollection *sc = outliner_scene_collection_from_tree_element(te);
BKE_collection_rename(scene, sc, te->name);
break;
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
tselem->flag &= ~TSE_TEXTBUT;
}
}
static void outliner_draw_restrictbuts(uiBlock *block, Scene *scene, ARegion *ar, SpaceOops *soops, ListBase *lb)
{
uiBut *bt;
TreeElement *te;
TreeStoreElem *tselem;
Object *ob = NULL;
Cleanup: remove BLI_blenlib from ghash header This causes source files to depend on ghash header for BLI_string/rect/listbase. Also quiet warnings.
2017-11-14 17:00:10 +11:00
#if 0
Outliner: minor speedup for drawing, avoid 3 rna lookups per object also for movie-clip dope-sheet
2014-01-17 08:37:45 +11:00
PropertyRNA *object_prop_hide, *object_prop_hide_select, *object_prop_hide_render;
/* get RNA properties (once) */
object_prop_hide = RNA_struct_type_find_property(&RNA_Object, "hide");
object_prop_hide_select = RNA_struct_type_find_property(&RNA_Object, "hide_select");
object_prop_hide_render = RNA_struct_type_find_property(&RNA_Object, "hide_render");
BLI_assert(object_prop_hide && object_prop_hide_select && object_prop_hide_render);
Cleanup: remove BLI_blenlib from ghash header This causes source files to depend on ghash header for BLI_string/rect/listbase. Also quiet warnings.
2017-11-14 17:00:10 +11:00
#endif
Outliner: minor speedup for drawing, avoid 3 rna lookups per object also for movie-clip dope-sheet
2014-01-17 08:37:45 +11:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (te = lb->first; te; te = te->next) {
tselem = TREESTORE(te);
if (te->ys + 2 * UI_UNIT_Y >= ar->v2d.cur.ymin && te->ys <= ar->v2d.cur.ymax) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* scene render layers and passes have toggle-able flags too! */
Render Layers and Collections (merge from render-layers) Design Documents ---------------- * https://wiki.blender.org/index.php/Dev:2.8/Source/Layers * https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised User Commit Log --------------- * New Layer and Collection system to replace render layers and viewport layers. * A layer is a set of collections of objects (and their drawing options) required for specific tasks. * A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers. * All Scenes have a master collection that all other collections are children of. * New collection "context" tab (in Properties Editor) * New temporary viewport "collections" panel to control per-collection visibility Missing User Features --------------------- * Collection "Filter" Option to add objects based on their names * Collection Manager operators The existing buttons are placeholders * Collection Manager drawing The editor main region is empty * Collection Override * Per-Collection engine settings This will come as a separate commit, as part of the clay-engine branch Dev Commit Log -------------- * New DNA file (DNA_layer_types.h) with the new structs We are replacing Base by a new extended Base while keeping it backward compatible with some legacy settings (i.e., lay, flag_legacy). Renamed all Base to BaseLegacy to make it clear the areas of code that still need to be converted Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp * Unittesting for main syncronization requirements - read, write, add/copy/remove objects, copy scene, collection link/unlinking, context) * New Editor: Collection Manager Based on patch by Julian Eisel This is extracted from the layer-manager branch. With the following changes: - Renamed references of layer manager to collections manager - I doesn't include the editors/space_collections/ draw and util files - The drawing code itself will be implemented separately by Julian * Base / Object: A little note about them. Original Blender code would try to keep them in sync through the code, juggling flags back and forth. This will now be handled by Depsgraph, keeping Object and Bases more separated throughout the non-rendering code. Scene.base is being cleared in doversion, and the old viewport drawing code was poorly converted to use the new bases while the new viewport code doesn't get merged and replace the old one. Python API Changes ------------------ ``` - scene.layers + # no longer exists - scene.objects + scene.scene_layers.active.objects - scene.objects.active + scene.render_layers.active.objects.active - bpy.context.scene.objects.link() + bpy.context.scene_collection.objects.link() - bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None) + bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None) - bpy.context.object.select + bpy.context.object.select = True + bpy.context.object.select = False + bpy.context.object.select_get() + bpy.context.object.select_set(action='SELECT') + bpy.context.object.select_set(action='DESELECT') -AddObjectHelper.layers + # no longer exists ```
2017-02-07 10:18:38 +01:00
if (tselem->type == TSE_R_LAYER) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Rename any instance of scene layer or render layer in code with view layer The RenderResult struct still has a listbase of RenderLayer, but that's ok since this is strictly for rendering. * Subversion bump (to 2.80.2) * DNA low level doversion (renames) - only for .blend created since 2.80 started Note: We can't use DNA_struct_elem_find or get file version in init_structDNA, so we are manually iterating over the array of the SDNA elements instead. Note 2: This doversion change with renames can be reverted in a few months. But so far it's required for 2.8 files created between October 2016 and now. Reviewers: campbellbarton, sergey Differential Revision: https://developer.blender.org/D2927
2017-11-22 10:52:39 -02:00
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, VIEW_LAYER_RENDER, 0, ICON_CHECKBOX_HLT - 1,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, te->directdata, 0, 0, 0, 0, TIP_("Render this RenderLayer"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_r_lay_cb, tselem->id, NULL);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (tselem->type == TSE_R_PASS) {
int *layflag = te->directdata;
int passflag = 1 << tselem->nr;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, passflag, 0, ICON_CHECKBOX_HLT - 1,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, layflag, 0, 0, 0, 0, TIP_("Render this Pass"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_r_lay_cb, tselem->id, NULL);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
layflag++; /* is lay_xor */
Defines: replace ELEM3-16 with ELEM(...), that can take varargs
2014-07-20 01:30:29 +10:00
if (ELEM(passflag, SCE_PASS_SPEC, SCE_PASS_SHADOW, SCE_PASS_AO, SCE_PASS_REFLECT, SCE_PASS_REFRACT,
style cleanup: wrap long lines (>200)
2012-12-23 01:18:35 +00:00
SCE_PASS_INDIRECT, SCE_PASS_EMIT, SCE_PASS_ENVIRONMENT))
{
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButBitI(block, UI_BTYPE_TOGGLE, passflag, 0, (*layflag & passflag) ? ICON_DOT : ICON_BLANK1,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, layflag, 0, 0, 0, 0, TIP_("Exclude this Pass from Combined"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_r_lay_cb, tselem->id, NULL);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
style cleanup: wrap long lines (>200)
2012-12-23 01:18:35 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (tselem->type == TSE_MODIFIER) {
ModifierData *md = (ModifierData *)te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
ob = (Object *)tselem->id;
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE_N, eModifierMode_Realtime, 0, ICON_RESTRICT_VIEW_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(md->mode), 0, 0, 0, 0,
TIP_("Restrict/Allow visibility in the 3D View"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_modifier_cb, scene, ob);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE_N, eModifierMode_Render, 0, ICON_RESTRICT_RENDER_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_RENDERX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(md->mode), 0, 0, 0, 0, TIP_("Restrict/Allow renderability"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_modifier_cb, scene, ob);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
Fix #35284: outline name edit textbox did not show properly in some cases. Also fix issues with its size not scaling with DPI.
2013-05-10 19:54:32 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (tselem->type == TSE_POSE_CHANNEL) {
bPoseChannel *pchan = (bPoseChannel *)te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Bone *bone = pchan->bone;
Ouliner: Added recursive setting of (visibility/selectability) for bones (Edit- and Object-mode)
2013-03-12 13:03:58 +00:00
ob = (Object *)tselem->id;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, BONE_HIDDEN_P, 0, ICON_RESTRICT_VIEW_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(bone->flag), 0, 0, 0, 0,
TIP_("Restrict/Allow visibility in the 3D View"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_bone_visibility_cb, ob->data, bone);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, BONE_UNSELECTABLE, 0, ICON_RESTRICT_SELECT_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(bone->flag), 0, 0, 0, 0,
TIP_("Restrict/Allow selection in the 3D View"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_bone_select_cb, ob->data, bone);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
Fix #35284: outline name edit textbox did not show properly in some cases. Also fix issues with its size not scaling with DPI.
2013-05-10 19:54:32 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (tselem->type == TSE_EBONE) {
EditBone *ebone = (EditBone *)te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, BONE_HIDDEN_A, 0, ICON_RESTRICT_VIEW_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(ebone->flag), 0, 0, 0, 0,
TIP_("Restrict/Allow visibility in the 3D View"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_ebone_visibility_cb, NULL, ebone);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefIconButBitI(block, UI_BTYPE_ICON_TOGGLE, BONE_UNSELECTABLE, 0, ICON_RESTRICT_SELECT_OFF,
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y, &(ebone->flag), 0, 0, 0, 0,
TIP_("Restrict/Allow selection in the 3D View"));
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_set(bt, restrictbutton_ebone_select_cb, NULL, ebone);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
Fix #35284: outline name edit textbox did not show properly in some cases. Also fix issues with its size not scaling with DPI.
2013-05-10 19:54:32 +00:00
GPencil: Viewport visbility and editability toggles for layers in Outliner * Viewport visibility and locking are currently exposed * Later on, visibility in renders can also be included
2015-02-09 12:34:17 +13:00
UI_block_emboss_set(block, UI_EMBOSS);
}
else if (tselem->type == TSE_GP_LAYER) {
bGPDlayer *gpl = (bGPDlayer *)te->directdata;
UI_block_emboss_set(block, UI_EMBOSS_NONE);
bt = uiDefIconButBitS(block, UI_BTYPE_ICON_TOGGLE, GP_LAYER_HIDE, 0, ICON_RESTRICT_VIEW_OFF,
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
UI_UNIT_Y, &gpl->flag, 0, 0, 0, 0,
TIP_("Restrict/Allow visibility in the 3D View"));
UI_but_func_set(bt, restrictbutton_gp_layer_flag_cb, NULL, gpl);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
bt = uiDefIconButBitS(block, UI_BTYPE_ICON_TOGGLE, GP_LAYER_LOCKED, 0, ICON_UNLOCKED,
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
UI_UNIT_Y, &gpl->flag, 0, 0, 0, 0,
TIP_("Restrict/Allow editing of strokes and keyframes in this layer"));
UI_but_func_set(bt, restrictbutton_gp_layer_flag_cb, NULL, gpl);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
/* TODO: visibility in renders */
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
}
Outliner: "All Collections" mode showing the master collection hierarchy Reordering is disabled for now. Link, unlink and override operators are only available while in "Active Layer" mode, not in "All Collections".
2017-02-27 22:17:19 +01:00
else if (tselem->type == TSE_LAYER_COLLECTION) {
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
LayerCollection *collection = te->directdata;
Layer collection enable flag Right now this is exposed in the outliner, though all this (visible/selectable/enable) should be moved to a new panel soon. This removes objects from the depsgraph when the collection is disabled. It allows you to "hide" lamps but still having them lighting the scene. Same for light probes and other support objects. Pending tasks: * Have depsgraph to include invisible objects in the DEG_OBJECTS_ITER, and then have Eevee and other engines to make a distinction between an invisible and a visible object. (for example, we probably want invisible objects to not show in the viewport, but cast shadows and show up in light probes). * Change how we evaluate collection settings so that an invisible collection can force an object to be invisible. Reviewers: campbellbarton Subscribers: sergey Differential Revision: https://developer.blender.org/D2848
2017-09-20 14:15:35 +02:00
const bool is_enabled = (collection->flag & COLLECTION_DISABLED) == 0;
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
UI_block_emboss_set(block, UI_EMBOSS_NONE);
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
if (collection->scene_collection->type == COLLECTION_TYPE_NONE) {
bt = uiDefIconButBitS(block, UI_BTYPE_ICON_TOGGLE_N, COLLECTION_SELECTABLE, 0, ICON_RESTRICT_SELECT_OFF,
Cleanup: whitespace
2017-12-04 17:19:34 +11:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
UI_UNIT_Y, &collection->flag, 0, 0, 0, 0,
TIP_("Restrict/Allow 3D View selection of objects in the collection"));
Groups and collection: initial integration Since we are ditching layers from Blender (2.8) we need a replacement to control groups visibility. This commit introduces collections as the building blocks for groups, allowing users to control visibility as well as overrides for groups. Features ======== * Groups now have collections This way you can change the visibility of a collection inside a group, and add overrides which are part of the group and are prioritized over other overrides. * Outliner Groups can inspect their collections, change visibility, and add/remove members. To change an override of a group collection, you need to select an instance of the group, and then you can choose "group" in the collection properties editor to edit this group active collection instead of the view layer one. * Dupli groups overrides We can now have multiple instances of the same group with an original "override" and different overrides depending on the collection the instanced object is part of. Technical ========= * Layers We use the same api for groups and scene as much as possible. Reviewers: sergey (depsgraph), mont29 (read/write and user count) Differential Revision: https://developer.blender.org/D2892
2017-12-01 11:24:21 -02:00
UI_but_func_set(bt, restrictbutton_collection_flag_cb, scene, collection);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
}
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
else if ((soops->outlinevis == SO_GROUPS) &&
(collection->scene_collection->type == COLLECTION_TYPE_GROUP_INTERNAL))
{
bt = uiDefIconButBitS(block, UI_BTYPE_ICON_TOGGLE_N, COLLECTION_VIEWPORT, 0, ICON_RESTRICT_VIEW_OFF,
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X,
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
UI_UNIT_Y, &collection->flag, 0, 0, 0, 0,
TIP_("Restrict/Allow 3D View selection of objects in the collection"));
UI_but_func_set(bt, restrictbutton_collection_flag_cb, tselem->id, collection);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
bt = uiDefIconButBitS(block, UI_BTYPE_ICON_TOGGLE_N, COLLECTION_RENDER, 0, ICON_RESTRICT_RENDER_OFF,
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys, UI_UNIT_X,
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
UI_UNIT_Y, &collection->flag, 0, 0, 0, 0,
TIP_("Restrict/Allow 3D View selection of objects in the collection"));
UI_but_func_set(bt, restrictbutton_collection_flag_cb, tselem->id, collection);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
}
bt = uiDefIconButBitS(block, UI_BTYPE_BUT_TOGGLE, COLLECTION_DISABLED, 0,
is_enabled ? ICON_CHECKBOX_HLT : ICON_CHECKBOX_DEHLT,
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_RENDERX), te->ys, UI_UNIT_X,
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
UI_UNIT_Y, &collection->flag, 0, 0, 0, 0,
TIP_("Enable/Disable collection"));
UI_but_func_set(bt, restrictbutton_collection_flag_cb, tselem->id, collection);
UI_but_flag_enable(bt, UI_BUT_DRAG_LOCK);
Support displaying collections in outliner Adds a new outliner display mode "Collections" which draws the active collection. We might want to rename it to "Active Collection" if we don't plan to support showing other collections there. Also added the buttons for restricting visibility and selectability. @dfelinto, code in restrictbutton_collection_hide_cb and restrictbutton_collection_hide_select_cb is duplicated from rna_LayerCollection_hide_update and rna_LayerCollection_hide_select_update, maybe utility functions would be handy for this?
2017-02-09 17:19:07 +01:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops)) outliner_draw_restrictbuts(block, scene, ar, soops, &te->subtree);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
static void outliner_draw_userbuts(uiBlock *block, ARegion *ar, SpaceOops *soops, ListBase *lb)
{
uiBut *bt;
TreeElement *te;
TreeStoreElem *tselem;
for (te = lb->first; te; te = te->next) {
tselem = TREESTORE(te);
if (te->ys + 2 * UI_UNIT_Y >= ar->v2d.cur.ymin && te->ys <= ar->v2d.cur.ymax) {
if (tselem->type == 0) {
ID *id = tselem->id;
const char *tip = NULL;
int icon = ICON_NONE;
char buf[16] = "";
int but_flag = UI_BUT_DRAG_LOCK;
Rename ID_IS_LINKED_DATABLOCK to ID_IS_LINKED. This makes code closer to id_override/assent-engine ones, which introduce a new type of linked data, and hence reserve ID_IS_LINKED_DATABLOCK to real linked datablocks.
2017-11-06 17:17:10 +01:00
if (ID_IS_LINKED(id))
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
but_flag |= UI_BUT_DISABLED;
UI_block_emboss_set(block, UI_EMBOSS_NONE);
if (id->flag & LIB_FAKEUSER) {
icon = ICON_FILE_TICK;
UI Messages: Consistent spelling of term "data-block" Was using a bunch of different spellings, mostly "data-block" though, so went with that one (would have been my #1 choice anyway ;) )
2016-09-19 16:46:20 +02:00
tip = TIP_("Data-block will be retained using a fake user");
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
}
else {
icon = ICON_X;
UI Messages: Consistent spelling of term "data-block" Was using a bunch of different spellings, mostly "data-block" though, so went with that one (would have been my #1 choice anyway ;) )
2016-09-19 16:46:20 +02:00
tip = TIP_("Data-block has no users and will be deleted");
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
}
bt = uiDefIconButBitS(block, UI_BTYPE_TOGGLE, LIB_FAKEUSER, 1, icon,
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), te->ys, UI_UNIT_X, UI_UNIT_Y,
&id->flag, 0, 0, 0, 0, tip);
UI_but_func_set(bt, restrictbutton_id_user_toggle, id, NULL);
UI_but_flag_enable(bt, but_flag);
BLI_str_format_int_grouped(buf, id->us);
bt = uiDefBut(block, UI_BTYPE_BUT, 1, buf,
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), te->ys,
UI_UNIT_X, UI_UNIT_Y, NULL, 0.0, 0.0, 0, 0,
UI Messages: Consistent spelling of term "data-block" Was using a bunch of different spellings, mostly "data-block" though, so went with that one (would have been my #1 choice anyway ;) )
2016-09-19 16:46:20 +02:00
TIP_("Number of users of this data-block"));
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
UI_but_flag_enable(bt, but_flag);
UI messages fixes and cleanup.
2015-02-16 20:00:20 +01:00
bt = uiDefButBitS(block, UI_BTYPE_TOGGLE, LIB_FAKEUSER, 1, (id->flag & LIB_FAKEUSER) ? "F" : " ",
(int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_RENDERX), te->ys, UI_UNIT_X, UI_UNIT_Y,
&id->flag, 0, 0, 0, 0,
UI Messages: Consistent spelling of term "data-block" Was using a bunch of different spellings, mostly "data-block" though, so went with that one (would have been my #1 choice anyway ;) )
2016-09-19 16:46:20 +02:00
TIP_("Data-block has a 'fake' user which will keep it in the file "
UI messages fixes and cleanup.
2015-02-16 20:00:20 +01:00
"even if nothing else uses it"));
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
UI_but_func_set(bt, restrictbutton_id_user_toggle, id, NULL);
UI_but_flag_enable(bt, but_flag);
UI_block_emboss_set(block, UI_EMBOSS);
}
}
if (TSELEM_OPEN(tselem, soops)) outliner_draw_userbuts(block, ar, soops, &te->subtree);
}
}
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
static void UNUSED_FUNCTION(outliner_draw_rnacols)(ARegion *ar, int sizex)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
View2D *v2d = &ar->v2d;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Region scrollbar fix! Now scrollbars correctly hide and show, making space for the actual contents in a region. It solves several old hacks, and puts view2d code a bit more back in control as well. Implementation notes: - The view2d mask feature is working again - The #define V2D_SCROLL_HORIZONTAL_HIDE means: "turn on hiding". - Code for UI_view2d_region_reinit() is enforcing better standard view settings But... two hack/patches needed to be added: - Region panel drawing: if after generating the button panels it appears a scroller hides or reveils, it calls all the generating code again. (a simple scale doesn't work due to rounding differences in layout code) - View2d code that maps 'tot' and 'cur' rects: if this code detects that the mask changes, it calcs the map code again. Also a bugfix (issue in 2.65) - The left/bottom area split widget was drawing 1 pixel too large sometimes, leaving bad trails on moving area dividers.
2012-12-26 13:05:39 +00:00
float miny = v2d->cur.ymin;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (miny < v2d->tot.ymin) miny = v2d->tot.ymin;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
glLineWidth(1.0f);
OpenGL immediate mode: finish outliner_draw.c Part of T49043
2017-03-07 01:40:40 -03:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
unsigned int pos = GWN_vertformat_attr_add(immVertexFormat(), "pos", GWN_COMP_F32, 2, GWN_FETCH_FLOAT);
OpenGL immediate mode: finish outliner_draw.c Part of T49043
2017-03-07 01:40:40 -03:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
immUniformThemeColorShadeAlpha(TH_BACK, -15, -200);
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
immBegin(GWN_PRIM_LINES, 4);
OpenGL immediate mode: finish outliner_draw.c Part of T49043
2017-03-07 01:40:40 -03:00
immVertex2f(pos, sizex, v2d->cur.ymax);
immVertex2f(pos, sizex, miny);
immVertex2f(pos, sizex + OL_RNA_COL_SIZEX, v2d->cur.ymax);
immVertex2f(pos, sizex + OL_RNA_COL_SIZEX, miny);
immEnd();
immUnbindProgram();
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
#if 0
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void outliner_draw_rnabuts(uiBlock *block, ARegion *ar, SpaceOops *soops, int sizex, ListBase *lb)
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
{
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
TreeElement *te;
TreeStoreElem *tselem;
PointerRNA *ptr;
PropertyRNA *prop;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (te = lb->first; te; te = te->next) {
tselem = TREESTORE(te);
if (te->ys + 2 * UI_UNIT_Y >= ar->v2d.cur.ymin && te->ys <= ar->v2d.cur.ymax) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tselem->type == TSE_RNA_PROPERTY) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
ptr = &te->rnaptr;
prop = te->directdata;
Fix T39692: Text fields in datablocks editor are broken Make RNAPointer props un-editable here, we simply cannot handle this. Also correct previous commit, asking for autonaming for all items was a bit extreme, this is only needed for enums!
2014-04-27 22:33:05 +02:00
if (!TSELEM_OPEN(tselem, soops)) {
if (RNA_property_type(prop) == PROP_POINTER) {
uiBut *but = uiDefAutoButR(block, ptr, prop, -1, "", ICON_NONE, sizex, te->ys,
OL_RNA_COL_SIZEX, UI_UNIT_Y - 1);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_flag_enable(but, UI_BUT_DISABLED);
Fix T39692: Text fields in datablocks editor are broken Make RNAPointer props un-editable here, we simply cannot handle this. Also correct previous commit, asking for autonaming for all items was a bit extreme, this is only needed for enums!
2014-04-27 22:33:05 +02:00
}
else if (RNA_property_type(prop) == PROP_ENUM) {
uiDefAutoButR(block, ptr, prop, -1, NULL, ICON_NONE, sizex, te->ys, OL_RNA_COL_SIZEX,
UI_UNIT_Y - 1);
}
else {
uiDefAutoButR(block, ptr, prop, -1, "", ICON_NONE, sizex, te->ys, OL_RNA_COL_SIZEX,
UI_UNIT_Y - 1);
}
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
else if (tselem->type == TSE_RNA_ARRAY_ELEM) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
ptr = &te->rnaptr;
prop = te->directdata;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Fix T39692: Text fields in datablocks editor are broken Make RNAPointer props un-editable here, we simply cannot handle this. Also correct previous commit, asking for autonaming for all items was a bit extreme, this is only needed for enums!
2014-04-27 22:33:05 +02:00
uiDefAutoButR(block, ptr, prop, te->index, "", ICON_NONE, sizex, te->ys, OL_RNA_COL_SIZEX,
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
UI_UNIT_Y - 1);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
if (TSELEM_OPEN(tselem, soops)) outliner_draw_rnabuts(block, ar, soops, sizex, &te->subtree);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Fix #35284: outline name edit textbox did not show properly in some cases. Also fix issues with its size not scaling with DPI.
2013-05-10 19:54:32 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_emboss_set(block, UI_EMBOSS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
#endif
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
static void outliner_buttons(const bContext *C, uiBlock *block, ARegion *ar, TreeElement *te)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
uiBut *bt;
TreeStoreElem *tselem;
int spx, dx, len;
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
tselem = TREESTORE(te);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
BLI_assert(tselem->flag & TSE_TEXTBUT);
/* If we add support to rename Sequence.
* need change this.
*/
if (tselem->type == TSE_EBONE) len = sizeof(((EditBone *) 0)->name);
else if (tselem->type == TSE_MODIFIER) len = sizeof(((ModifierData *) 0)->name);
else if (tselem->id && GS(tselem->id->name) == ID_LI) len = sizeof(((Library *) 0)->name);
else len = MAX_ID_NAME - 2;
spx = te->xs + 1.8f * UI_UNIT_X;
dx = ar->v2d.cur.xmax - (spx + 3.2f * UI_UNIT_X);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
bt = uiDefBut(block, UI_BTYPE_TEXT, OL_NAMEBUTTON, "", spx, te->ys, dx, UI_UNIT_Y - 1, (void *)te->name,
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
1.0, (float)len, 0, 0, "");
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_func_rename_set(bt, namebutton_cb, tselem);
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
/* returns false if button got removed */
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
if (false == UI_but_active_only(C, ar, block, bt)) {
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
tselem->flag &= ~TSE_TEXTBUT;
/* bad! (notifier within draw) without this, we don't get a refesh */
WM_event_add_notifier(C, NC_SPACE | ND_SPACE_OUTLINER, NULL);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
/* ****************************************************** */
/* Normal Drawing... */
/* make function calls a bit compacter */
struct DrawIconArg {
uiBlock *block;
ID *id;
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
float xmax, x, y, xb, yb;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
float alpha;
};
static void tselem_draw_icon_uibut(struct DrawIconArg *arg, int icon)
{
style cleanup - comment spelling + translate some dutch.
2012-03-04 04:35:12 +00:00
/* restrict column clip... it has been coded by simply overdrawing, doesnt work for buttons */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (arg->x >= arg->xmax) {
Fix #29443: Outliner buttons hover on shrink Issue was caused by drawing icon instead of button due to column clip. This icons was drawing without taking icons' alpha into account.
2011-11-29 08:36:24 +00:00
glEnable(GL_BLEND);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
UI_icon_draw_alpha(arg->x, arg->y, icon, arg->alpha);
Fix #29443: Outliner buttons hover on shrink Issue was caused by drawing icon instead of button due to column clip. This icons was drawing without taking icons' alpha into account.
2011-11-29 08:36:24 +00:00
glDisable(GL_BLEND);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
}
else {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
uiBut *but = uiDefIconBut(arg->block, UI_BTYPE_LABEL, 0, icon, arg->xb, arg->yb, UI_UNIT_X, UI_UNIT_Y, NULL,
Replace of (id->lib != NULL) check by meaningful macro. Idea is to replace hard-to-track (id->lib != NULL) 'is linked datablock' check everywhere in Blender by a macro doing the same thing. This will allow to easily spot those checks in future, and more importantly, to easily change it (see work done in asset-engine branch). Note: did not touch to readfile.c, since there most of the time 'id->lib' check actually concerns the pointer, and not a check whether ID is linked or not. Will have a closer look at it later. Reviewers: campbellbarton, brecht, sergey Differential Revision: https://developer.blender.org/D2082
2016-07-06 14:11:01 +02:00
0.0, 0.0, 1.0, arg->alpha,
Rename ID_IS_LINKED_DATABLOCK to ID_IS_LINKED. This makes code closer to id_override/assent-engine ones, which introduce a new type of linked data, and hence reserve ID_IS_LINKED_DATABLOCK to real linked datablocks.
2017-11-06 17:17:10 +01:00
(arg->id && ID_IS_LINKED(arg->id)) ? arg->id->lib->name : "");
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (arg->id)
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_but_drag_set_id(but, arg->id);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Grease Pencil v2 Branch Improve current Grease Pencil in order to get a better 2D animation tool. More info in WIKI pages: https://wiki.blender.org/index.php/User:Antoniov Reviewed By: Severin, aligorith, campbellbarton Patch by @antoniov, with edits by @Severin. Differential Revision: https://developer.blender.org/D2115
2016-08-03 23:31:48 +02:00
static void UNUSED_FUNCTION(tselem_draw_gp_icon_uibut)(struct DrawIconArg *arg, ID *id, bGPDlayer *gpl)
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
{
/* restrict column clip - skip it for now... */
if (arg->x >= arg->xmax) {
/* pass */
}
else {
PointerRNA ptr;
outliner: tweak GPLayer color button overlap
2015-08-22 16:48:41 +10:00
const float eps = 0.001f;
const bool is_stroke_visible = (gpl->color[3] > eps);
const bool is_fill_visible = (gpl->fill[3] > eps);
float w = 0.5f * UI_UNIT_X;
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
float h = 0.85f * UI_UNIT_Y;
outliner: tweak GPLayer color button overlap
2015-08-22 16:48:41 +10:00
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
RNA_pointer_create(id, &RNA_GPencilLayer, gpl, &ptr);
outliner: tweak GPLayer color button overlap
2015-08-22 16:48:41 +10:00
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
UI_block_align_begin(arg->block);
outliner: tweak GPLayer color button overlap
2015-08-22 16:48:41 +10:00
UI_block_emboss_set(arg->block, is_stroke_visible ? UI_EMBOSS : UI_EMBOSS_NONE);
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
uiDefButR(arg->block, UI_BTYPE_COLOR, 1, "", arg->xb, arg->yb, w, h,
&ptr, "color", -1,
0, 0, 0, 0, NULL);
outliner: tweak GPLayer color button overlap
2015-08-22 16:48:41 +10:00
UI_block_emboss_set(arg->block, is_fill_visible ? UI_EMBOSS : UI_EMBOSS_NONE);
uiDefButR(arg->block, UI_BTYPE_COLOR, 1, "", arg->xb + w, arg->yb, w, h,
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
&ptr, "fill_color", -1,
0, 0, 0, 0, NULL);
UI_block_emboss_set(arg->block, UI_EMBOSS_NONE);
UI_block_align_end(arg->block);
}
}
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
static void tselem_draw_icon(uiBlock *block, int xmax, float x, float y, TreeStoreElem *tselem, TreeElement *te,
float alpha)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
struct DrawIconArg arg;
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
float aspect;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* make function calls a bit compacter */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
arg.block = block;
arg.id = tselem->id;
style cleanup: mainly for mesh code, also some WM function use.
2012-03-24 02:51:46 +00:00
arg.xmax = xmax;
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
arg.xb = x; /* for ui buttons */
arg.yb = y;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
arg.alpha = alpha;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
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
/* placement of icons, copied from interface_widgets.c */
aspect = (0.8f * UI_UNIT_Y) / ICON_DEFAULT_HEIGHT;
Various icon adjustments
2017-03-17 16:47:19 +03:00
x += 2.0f * aspect;
y += 2.0f * aspect;
fix redundant assignment Thanks clang for the warning.
2017-03-22 16:26:53 -04:00
arg.x = x;
arg.y = y;
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
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
#define ICON_DRAW(_icon) UI_icon_draw_alpha(x, y, _icon, alpha)
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tselem->type) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
switch (tselem->type) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_ANIM_DATA:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_ANIM_DATA); /* XXX */
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_NLA:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_NLA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_NLA_TRACK:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_NLA); /* XXX */
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_NLA_ACTION:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_ACTION);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_DRIVER_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_DRIVER);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_DEFGROUP_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_GROUP_VERTEX);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_BONE:
case TSE_EBONE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_BONE_DATA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_CONSTRAINT_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_CONSTRAINT);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_MODIFIER_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MODIFIER);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_LINKED_OB:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_OBJECT_DATA);
break;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
case TSE_LINKED_PSYS:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_PARTICLES);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_MODIFIER:
{
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Object *ob = (Object *)tselem->id;
ModifierData *md = BLI_findlink(&ob->modifiers, tselem->nr);
Code cleanup: better warning in case of modifier icons in outliner. Modified the switch statement to use the ModifierType enum and changed the default case to use specific missing values. Compiler can then issue warnings when new modifier types are added (at least gcc 4.6.3 does)
2012-05-22 18:40:31 +00:00
switch ((ModifierType)md->type) {
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
case eModifierType_Subsurf:
ICON_DRAW(ICON_MOD_SUBSURF);
break;
case eModifierType_Armature:
ICON_DRAW(ICON_MOD_ARMATURE);
break;
case eModifierType_Lattice:
ICON_DRAW(ICON_MOD_LATTICE);
break;
case eModifierType_Curve:
ICON_DRAW(ICON_MOD_CURVE);
break;
case eModifierType_Build:
ICON_DRAW(ICON_MOD_BUILD);
break;
case eModifierType_Mirror:
ICON_DRAW(ICON_MOD_MIRROR);
break;
case eModifierType_Decimate:
ICON_DRAW(ICON_MOD_DECIM);
break;
case eModifierType_Wave:
ICON_DRAW(ICON_MOD_WAVE);
break;
case eModifierType_Hook:
ICON_DRAW(ICON_HOOK);
break;
case eModifierType_Softbody:
ICON_DRAW(ICON_MOD_SOFT);
break;
case eModifierType_Boolean:
ICON_DRAW(ICON_MOD_BOOLEAN);
break;
case eModifierType_ParticleSystem:
ICON_DRAW(ICON_MOD_PARTICLES);
break;
Revert particle system and point cache removal in blender2.8 branch. This reverts commit 5aa19be91263a249ffae75573e3b32f24269d890 and b4a721af694817fa921b119df83d33ede7d7fed0. Due to postponement of particle system rewrite it was decided to put particle code back into the 2.8 branch for the time being.
2016-12-28 17:30:58 +01:00
case eModifierType_ParticleInstance:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_PARTICLES);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_EdgeSplit:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_EDGESPLIT);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Array:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_ARRAY);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_UVProject:
UV Warp Modifier: Based on patch [#30837] UV Offset Modifier by Pawel Kowal (pkowal) - Allows you to setup a transformation between objects to apply to UV coords. - Option to select which axis apply to U/V. - Option to select the UV center (needed for transformations that scale or rotate). - Uses from/to objects in a similar way to the Warp modifier. - Vertex group can be used to adjust influence.
2012-12-14 04:07:30 +00:00
case eModifierType_UVWarp: /* TODO, get own icon */
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_UVPROJECT);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Displace:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_DISPLACE);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Shrinkwrap:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SHRINKWRAP);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Cast:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_CAST);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_MeshDeform:
Surface Deform Modifier (SDef) Implementation of the SDef modifier, which allows meshes to be bound by surface, thus allowing things such as cloth simulation proxies. User documentation: https://wiki.blender.org/index.php/User:Lucarood/SurfaceDeform Reviewers: mont29, sergey Subscribers: Severin, dfelinto, plasmasolutions, kjym3 Differential Revision: https://developer.blender.org/D2462
2017-02-27 12:39:14 -03:00
case eModifierType_SurfaceDeform:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MESHDEFORM);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Bevel:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_BEVEL);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Smooth:
Merge GSoC project from branch: Laplacian Smooth (Operator & Modifier) by Alexander Pinzon Fernandez (apinzonf) Supported by Google Summer of Code 2012 Project Documentation: http://wiki.blender.org/index.php/User:Apinzonf Manual Page: http://wiki.blender.org/index.php/User:Apinzonf/Doc:2.6/Manual/Modifiers/Deform/Laplacian_Smooth
2012-10-24 10:39:11 +00:00
case eModifierType_LaplacianSmooth:
Corrective Smooth Modifier (aka delta-mush) This modifier can be used to correct bad deformations, Original patch D1183 by @sazerac, with own modifications
2015-03-29 04:44:05 +11:00
case eModifierType_CorrectiveSmooth:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SMOOTH);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_SimpleDeform:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SIMPLEDEFORM);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Mask:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MASK);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Cloth:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_CLOTH);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Explode:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_EXPLODE);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Collision:
Code cleanup: better warning in case of modifier icons in outliner. Modified the switch statement to use the ModifierType enum and changed the default case to use specific missing values. Compiler can then issue warnings when new modifier types are added (at least gcc 4.6.3 does)
2012-05-22 18:40:31 +00:00
case eModifierType_Surface:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_PHYSICS);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Fluidsim:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_FLUIDSIM);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Multires:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MULTIRES);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Smoke:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SMOKE);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Solidify:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SOLIDIFY);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case eModifierType_Screw:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SCREW);
break;
Fix for Remesh Modifier: * Remesh Icon was missing in the outliner.
2011-12-30 21:29:02 +00:00
case eModifierType_Remesh:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_REMESH);
break;
WeightVG: added WeightVG icon for outliner (don’t know when that where lost...).
2011-09-16 16:05:45 +00:00
case eModifierType_WeightVGEdit:
case eModifierType_WeightVGMix:
case eModifierType_WeightVGProximity:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_VERTEX_WEIGHT);
break;
Merge with trunk r39589
2011-08-21 19:37:19 +00:00
case eModifierType_DynamicPaint:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_DYNAMICPAINT);
break;
Ocean Modifier UI fixes: * Modifier Icon was missing in the outliner * Fluid icon was used in the rna struct, fixed Note: Ocean uses the Wave modifier icon atm, if we find a better one, this can be changed.
2012-01-22 22:30:45 +00:00
case eModifierType_Ocean:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_OCEAN);
break;
2.6 UI Modifier Icons: * New Ocean Icon, created by Leon Cheung. Thanks! Approved by Lukas and myself. * New Warp Icon, created by "Zafio" Blender artists Thread where the Icons come from: http://blenderartists.org/forum/showthread.php?243354-Call-for-Modifier-Icons!
2012-02-12 19:57:47 +00:00
case eModifierType_Warp:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_WARP);
break;
Skin Modifier: * Show Modifier Icon in Outliner.
2012-05-22 18:20:07 +00:00
case eModifierType_Skin:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_SKIN);
break;
Triangulate modifier Useful for bump map baking where a consistent triangulation should be enforced when baking/exporting/importing, to avoid artifacts caused by a different triangulation of the mesh by that which was used for baking by internal/external tools. documentation is here http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/More_Features Will probably add some pictures too to demonstrate the issue that is solved more clearly. Currently using the skin modifier icon, will soon change that. Review by Brecht, thanks!
2012-11-19 20:40:08 +00:00
case eModifierType_Triangulate:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_TRIANGULATE);
break;
mesh-cache deform modifier, supports MDD and PC2 formats. see wiki docs: http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Deform/Mesh_Cache
2013-01-21 15:41:00 +00:00
case eModifierType_MeshCache:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MESHDEFORM); /* XXX, needs own icon */
break;
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
case eModifierType_MeshSequenceCache:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MESHDEFORM); /* XXX, needs own icon */
break;
Modifier: New Wireframe Modifier Based on patch originally by Thomas Beck, uses options similar to solidify.
2013-12-22 07:08:35 +11:00
case eModifierType_Wireframe:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_WIREFRAME);
break;
Mesh Modifiers: Added Laplacian Deform Part of soc-2013-sketch_mesh branch See: http://wiki.blender.org/index.php/User:Apinzonf/Doc:2.6/Manual/Modifiers/Deform/Laplacian_Deform
2013-11-24 07:00:49 +11:00
case eModifierType_LaplacianDeform:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_MESHDEFORM); /* XXX, needs own icon */
break;
Transfer data: add modifier. Not much to add, modifier uses same code as operator basically, only key difference is that modifier will never create data layers itself, you have to use dedicated operator for that.
2015-01-09 21:19:12 +01:00
case eModifierType_DataTransfer:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_DATA_TRANSFER);
break;
Custom Loop Normals: Add NormalEdit modifier Nothing much to say here, basic tool to make normals point toward a target, or to make them point 'outward' as if object was a spheroid (useful for game bushes etc.). Also, forgot a big thank you to Campbell for the extensive review work he has done on this project!
2015-02-05 14:49:44 +01:00
case eModifierType_NormalEdit:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MOD_NORMALEDIT);
break;
Code cleanup: better warning in case of modifier icons in outliner. Modified the switch statement to use the ModifierType enum and changed the default case to use specific missing values. Compiler can then issue warnings when new modifier types are added (at least gcc 4.6.3 does)
2012-05-22 18:40:31 +00:00
/* Default */
case eModifierType_None:
case eModifierType_ShapeKey:
style cleanup: indentation
2012-11-09 09:33:28 +00:00
case NUM_MODIFIER_TYPES:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_DOT);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
break;
}
case TSE_POSE_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_ARMATURE_DATA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_POSE_CHANNEL:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_BONE_DATA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_PROXY:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_GHOST);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_R_LAYER_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_RENDERLAYERS);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_R_LAYER:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_RENDERLAYERS);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_LINKED_LAMP:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_LAMP_DATA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_LINKED_MAT:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_MATERIAL_DATA);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_POSEGRP_BASE:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_GROUP_BONE);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
case TSE_SEQUENCE:
code cleanup: rename sequencer types to SEQ_TYPE_*** and use enums rather then defines.
2012-06-07 15:49:02 +00:00
if (te->idcode == SEQ_TYPE_MOVIE)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_SEQUENCE);
code cleanup: rename sequencer types to SEQ_TYPE_*** and use enums rather then defines.
2012-06-07 15:49:02 +00:00
else if (te->idcode == SEQ_TYPE_META)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_DOT);
code cleanup: rename sequencer types to SEQ_TYPE_*** and use enums rather then defines.
2012-06-07 15:49:02 +00:00
else if (te->idcode == SEQ_TYPE_SCENE)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_SCENE);
code cleanup: rename sequencer types to SEQ_TYPE_*** and use enums rather then defines.
2012-06-07 15:49:02 +00:00
else if (te->idcode == SEQ_TYPE_SOUND_RAM)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_SOUND);
code cleanup: rename sequencer types to SEQ_TYPE_*** and use enums rather then defines.
2012-06-07 15:49:02 +00:00
else if (te->idcode == SEQ_TYPE_IMAGE)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_IMAGE_COL);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
else
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_PARTICLES);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
break;
case TSE_SEQ_STRIP:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_LIBRARY_DATA_DIRECT);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
break;
case TSE_SEQUENCE_DUP:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_OBJECT_DATA);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
break;
case TSE_RNA_STRUCT:
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (RNA_struct_is_ID(te->rnaptr.type)) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
arg.id = (ID *)te->rnaptr.data;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
tselem_draw_icon_uibut(&arg, RNA_struct_ui_icon(te->rnaptr.type));
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
else {
int icon = RNA_struct_ui_icon(te->rnaptr.type);
ICON_DRAW(icon);
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
break;
Outliner: Use (temporary) icons for collections We need new icons for collections. Yet we are using them in a few places, so we may as well be consistent and use it everywhere.
2018-01-18 17:30:35 -02:00
case TSE_LAYER_COLLECTION:
case TSE_SCENE_COLLECTION:
ICON_DRAW(ICON_COLLAPSEMENU);
break;
Grease Pencil v2 Branch Improve current Grease Pencil in order to get a better 2D animation tool. More info in WIKI pages: https://wiki.blender.org/index.php/User:Antoniov Reviewed By: Severin, aligorith, campbellbarton Patch by @antoniov, with edits by @Severin. Differential Revision: https://developer.blender.org/D2115
2016-08-03 23:31:48 +02:00
/* Removed the icons from outliner. Need a better structure with Layers, Palettes and Colors */
#if 0
GPencil: Initial support for GP Layers in Outliner This is still very rudimentary, and lacks many things. * This needs a better icon. Perhaps we can look into using colour swatches here too like in all the other places? * The "active" check needs to be implemented still * Various restriction toggles to come still
2015-02-07 12:50:22 +13:00
case TSE_GP_LAYER:
GPencil: Show color swatches for GPencil layers in Outliner Instead of showing a meaningless "dot" icon or having to come up with an arbitrary icon, the Outliner now shows the stroke/fill color swatches for each layer to match every other place where these are shown. NOTE: Like many other widgets in the outliner though, these are not editable.
2015-02-09 12:39:03 +13:00
tselem_draw_gp_icon_uibut(&arg, tselem->id, te->directdata);
break;
Grease Pencil v2 Branch Improve current Grease Pencil in order to get a better 2D animation tool. More info in WIKI pages: https://wiki.blender.org/index.php/User:Antoniov Reviewed By: Severin, aligorith, campbellbarton Patch by @antoniov, with edits by @Severin. Differential Revision: https://developer.blender.org/D2115
2016-08-03 23:31:48 +02:00
#endif
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
default:
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ICON_DRAW(ICON_DOT);
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Fix T48830: Outliner draw crash, missing NULL check Fix from @cheleb
2016-07-12 14:39:39 +10:00
else if (tselem->id) {
if (GS(tselem->id->name) == ID_OB) {
Object *ob = (Object *)tselem->id;
switch (ob->type) {
case OB_LAMP:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_LAMP); break;
case OB_MESH:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_MESH); break;
case OB_CAMERA:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_CAMERA); break;
case OB_CURVE:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_CURVE); break;
case OB_MBALL:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_META); break;
case OB_LATTICE:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_LATTICE); break;
case OB_ARMATURE:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_ARMATURE); break;
case OB_FONT:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_FONT); break;
case OB_SURF:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_SURFACE); break;
case OB_SPEAKER:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_SPEAKER); break;
case OB_EMPTY:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_OB_EMPTY); break;
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Fix T48830: Outliner draw crash, missing NULL check Fix from @cheleb
2016-07-12 14:39:39 +10:00
else {
Make GS macro return proper IDType type Previously it was returning short, which was really easy to (a) compare against non-ID type value (b) forget to handle some specific value in switch statement. Both issues happened in the nearest past, so it's time to tighten some nuts here. Most of the change related on silencing strict compiler warning now, but there is also one tricky aspect: ID_NLA is not in the IDType enum. So there is still cast to short to handle that switch. If someone has better ideas how to deal with this please go ahead :)
2017-08-28 11:19:58 +02:00
/* TODO(sergey): Casting to short here just to handle ID_NLA which is
* NOT inside of IDType enum.
*/
switch ((short)GS(tselem->id->name)) {
Fix T48830: Outliner draw crash, missing NULL check Fix from @cheleb
2016-07-12 14:39:39 +10:00
case ID_SCE:
tselem_draw_icon_uibut(&arg, ICON_SCENE_DATA); break;
case ID_ME:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_MESH); break;
case ID_CU:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_CURVE); break;
case ID_MB:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_META); break;
case ID_LT:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_LATTICE); break;
case ID_LA:
{
Lamp *la = (Lamp *)tselem->id;
switch (la->type) {
case LA_LOCAL:
tselem_draw_icon_uibut(&arg, ICON_LAMP_POINT); break;
case LA_SUN:
tselem_draw_icon_uibut(&arg, ICON_LAMP_SUN); break;
case LA_SPOT:
tselem_draw_icon_uibut(&arg, ICON_LAMP_SPOT); break;
case LA_HEMI:
tselem_draw_icon_uibut(&arg, ICON_LAMP_HEMI); break;
case LA_AREA:
tselem_draw_icon_uibut(&arg, ICON_LAMP_AREA); break;
default:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_LAMP); break;
}
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Fix T48830: Outliner draw crash, missing NULL check Fix from @cheleb
2016-07-12 14:39:39 +10:00
case ID_MA:
tselem_draw_icon_uibut(&arg, ICON_MATERIAL_DATA); break;
case ID_TE:
tselem_draw_icon_uibut(&arg, ICON_TEXTURE_DATA); break;
case ID_IM:
tselem_draw_icon_uibut(&arg, ICON_IMAGE_DATA); break;
case ID_SPK:
case ID_SO:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_SPEAKER); break;
case ID_AR:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_ARMATURE); break;
case ID_CA:
tselem_draw_icon_uibut(&arg, ICON_OUTLINER_DATA_CAMERA); break;
case ID_KE:
tselem_draw_icon_uibut(&arg, ICON_SHAPEKEY_DATA); break;
case ID_WO:
tselem_draw_icon_uibut(&arg, ICON_WORLD_DATA); break;
case ID_AC:
tselem_draw_icon_uibut(&arg, ICON_ACTION); break;
case ID_NLA:
tselem_draw_icon_uibut(&arg, ICON_NLA); break;
case ID_TXT:
tselem_draw_icon_uibut(&arg, ICON_SCRIPT); break;
case ID_GR:
tselem_draw_icon_uibut(&arg, ICON_GROUP); break;
case ID_LI:
if (tselem->id->tag & LIB_TAG_MISSING) {
tselem_draw_icon_uibut(&arg, ICON_LIBRARY_DATA_BROKEN);
}
else if (((Library *)tselem->id)->parent) {
tselem_draw_icon_uibut(&arg, ICON_LIBRARY_DATA_INDIRECT);
}
else {
tselem_draw_icon_uibut(&arg, ICON_LIBRARY_DATA_DIRECT);
}
break;
case ID_LS:
tselem_draw_icon_uibut(&arg, ICON_LINE_DATA); break;
case ID_GD:
tselem_draw_icon_uibut(&arg, ICON_GREASEPENCIL); break;
Make GS macro return proper IDType type Previously it was returning short, which was really easy to (a) compare against non-ID type value (b) forget to handle some specific value in switch statement. Both issues happened in the nearest past, so it's time to tighten some nuts here. Most of the change related on silencing strict compiler warning now, but there is also one tricky aspect: ID_NLA is not in the IDType enum. So there is still cast to short to handle that switch. If someone has better ideas how to deal with this please go ahead :)
2017-08-28 11:19:58 +02:00
default:
break;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
#undef ICON_DRAW
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
static void outliner_draw_iconrow(bContext *C, uiBlock *block, Scene *scene, ViewLayer *view_layer, SpaceOops *soops,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ListBase *lb, int level, int xmax, int *offsx, int ys, float alpha_fac)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
TreeElement *te;
TreeStoreElem *tselem;
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
eOLDrawState active;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (te = lb->first; te; te = te->next) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* exit drawing early */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if ((*offsx) - UI_UNIT_X > xmax)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
break;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
tselem = TREESTORE(te);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* object hierarchy always, further constrained on level */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (level < 1 || (tselem->type == 0 && te->idcode == ID_OB)) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* active blocks get white circle */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (tselem->type == 0) {
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
if (te->idcode == ID_OB) {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
active = (OBACT(view_layer) == (Object *)tselem->id) ? OL_DRAWSEL_NORMAL : OL_DRAWSEL_NONE;
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
}
else if (scene->obedit && scene->obedit->data == tselem->id) {
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_NORMAL;
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
}
else {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
active = tree_element_active(C, scene, view_layer, soops, te, OL_SETSEL_NONE, false);
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
else {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
active = tree_element_type_active(C, scene, view_layer, soops, te, tselem, OL_SETSEL_NONE, false);
code cleanup: favor braces when blocks have mixed brace use.
2013-03-09 03:46:30 +00:00
}
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
if (active != OL_DRAWSEL_NONE) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
float ufac = UI_UNIT_X / 20.0f;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
float color[4] = {1.0f, 1.0f, 1.0f, 0.4f};
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_draw_roundbox_corner_set(UI_CNR_ALL);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
color[3] *= alpha_fac;
OpenGL: refactor UI_draw_roundbox functions Each function takes a bool (filled vs outline) and a color. We already had multiple ways of passing color in; these are still here. Special variant for anti-aliasing. - took GLenum out of interface - removed UI_RB_ALPHA flag (only one place really used it) - use exact vertex count - removed redundant state changes (BLEND, LINE_SMOOTH)
2017-04-06 19:15:26 -04:00
UI_draw_roundbox_aa(
true,
Various icon adjustments
2017-03-17 16:47:19 +03:00
(float) *offsx + 1.0f * ufac,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
(float)ys + 1.0f * ufac,
Various icon adjustments
2017-03-17 16:47:19 +03:00
(float)*offsx + UI_UNIT_X - 1.0f * ufac,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
(float)ys + UI_UNIT_Y - ufac,
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
(float)UI_UNIT_Y / 2.0f - ufac,
OpenGL: refactor UI_draw_roundbox functions Each function takes a bool (filled vs outline) and a color. We already had multiple ways of passing color in; these are still here. Special variant for anti-aliasing. - took GLenum out of interface - removed UI_RB_ALPHA flag (only one place really used it) - use exact vertex count - removed redundant state changes (BLEND, LINE_SMOOTH)
2017-04-06 19:15:26 -04:00
color);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
glEnable(GL_BLEND); /* roundbox disables */
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
tselem_draw_icon(block, xmax, (float)*offsx, (float)ys, tselem, te, 0.5f * alpha_fac);
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
te->xs = *offsx;
te->ys = ys;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
te->xend = (short)*offsx + UI_UNIT_X;
te->flag |= TE_ICONROW; // for click
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
(*offsx) += UI_UNIT_X;
}
spelling cleanup
2012-03-18 07:38:51 +00:00
/* this tree element always has same amount of branches, so don't draw */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (tselem->type != TSE_R_LAYER)
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
outliner_draw_iconrow(C, block, scene, view_layer, soops, &te->subtree, level + 1, xmax, offsx, ys, alpha_fac);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
/* closed tree element */
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void outliner_set_coord_tree_element(TreeElement *te, int startx, int starty)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
TreeElement *ten;
Outliner: Rework element selection behavior * LMB now replaces selection instead of adding to it. Shift+LMB adds to selection (or removes if already selected). This is usual selection behavior Blender. * Outliner selection isn't completely separate from object/sequencer-strip/render-layer/... selection anymore, when selecting an outliner item we now always try to select (and activate) the object it belongs to. Previously you had to click the name or icon of an item to select the object (or whatever) and on empty space within the row to set outliner selection. * Collapsed items may show click-able icons for their children (nothing new). Clicking on such an icon will also select the hidden item it represents now, you'll notice after opening the parent. This valid from a technical POV, I'm not sure if this is wanted from user POV though. Changing would be easy, feedback welcome! * Code cleanup. Part of T37430.
2016-10-16 02:53:11 +02:00
/* closed items may be displayed in row of parent, don't change their coordinate! */
if ((te->flag & TE_ICONROW) == 0) {
/* store coord and continue, we need coordinates for elements outside view too */
te->xs = startx;
te->ys = starty;
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (ten = te->subtree.first; ten; ten = ten->next) {
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
outliner_set_coord_tree_element(ten, startx + UI_UNIT_X, starty);
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
static void outliner_draw_tree_element(
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
bContext *C, uiBlock *block, const uiFontStyle *fstyle, Scene *scene, ViewLayer *view_layer,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
ARegion *ar, SpaceOops *soops, TreeElement *te, bool draw_grayed_out,
int startx, int *starty, TreeElement **te_edit, TreeElement **te_floating)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
TreeStoreElem *tselem;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
float ufac = UI_UNIT_X / 20.0f;
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
int offsx = 0;
eOLDrawState active = OL_DRAWSEL_NONE;
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
float color[4];
style cleanup: outliner
2012-05-07 17:56:30 +00:00
tselem = TREESTORE(te);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (*starty + 2 * UI_UNIT_Y >= ar->v2d.cur.ymin && *starty <= ar->v2d.cur.ymax) {
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
const float alpha_fac = draw_grayed_out ? 0.5f : 1.0f;
const float alpha = 0.5f * alpha_fac;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
int xmax = ar->v2d.cur.xmax;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
if ((tselem->flag & TSE_TEXTBUT) && (*te_edit == NULL)) {
*te_edit = te;
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
if ((te->drag_data != NULL) && (*te_floating == NULL)) {
*te_floating = te;
}
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
spelling cleanup
2012-03-18 07:38:51 +00:00
/* icons can be ui buts, we don't want it to overlap with restrict */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if ((soops->flag & SO_HIDE_RESTRICTCOLS) == 0)
xmax -= OL_TOGW + UI_UNIT_X;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
glEnable(GL_BLEND);
/* colors for active/selected data */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (tselem->type == 0) {
if (te->idcode == ID_SCE) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tselem->id == (ID *)scene) {
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
rgba_float_args_set(color, 1.0f, 1.0f, 1.0f, alpha);
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_ACTIVE;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (te->idcode == ID_OB) {
Object *ob = (Object *)tselem->id;
Outliner: Fix selection drawing Outliner was using the old selection flag to show selected objects. So if you selected an object in the outliner it would keep "selected" (drawn in yellow) even after you selected another object.
2017-12-13 16:23:56 -02:00
Base *base = (Base *)te->directdata;
const bool is_selected = (base != NULL) && ((base->flag & BASE_SELECTED) != 0);
if (ob == OBACT(view_layer) || is_selected) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
char col[4] = {0, 0, 0, 0};
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* outliner active ob: always white text, circle color now similar to view3d */
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_ACTIVE;
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
if (ob == OBACT(view_layer)) {
Outliner: Fix selection drawing Outliner was using the old selection flag to show selected objects. So if you selected an object in the outliner it would keep "selected" (drawn in yellow) even after you selected another object.
2017-12-13 16:23:56 -02:00
if (is_selected) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI_GetThemeColorType4ubv(TH_ACTIVE, SPACE_VIEW3D, col);
UI fixes: - on setting lower DPI, the regions that were scrolled down would start moving down 1 pixel on every draw. Caused by rounding error. (int + 0.1 vs int -0.1) (Ancient bug) - circles used in outliner - to denote selection/active - now draw bigger, and better centered. (2.66 fix only)
2012-12-17 17:37:48 +00:00
col[3] = alpha;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_NORMAL;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Outliner: Fix selection drawing Outliner was using the old selection flag to show selected objects. So if you selected an object in the outliner it would keep "selected" (drawn in yellow) even after you selected another object.
2017-12-13 16:23:56 -02:00
else if (is_selected) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI_GetThemeColorType4ubv(TH_SELECT, SPACE_VIEW3D, col);
UI fixes: - on setting lower DPI, the regions that were scrolled down would start moving down 1 pixel on every draw. Caused by rounding error. (int + 0.1 vs int -0.1) (Ancient bug) - circles used in outliner - to denote selection/active - now draw bigger, and better centered. (2.66 fix only)
2012-12-17 17:37:48 +00:00
col[3] = alpha;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
rgba_float_args_set(color, (float)col[0] / 255, (float)col[1] / 255, (float)col[2] / 255, alpha);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
else if (scene->obedit && scene->obedit->data == tselem->id) {
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
rgba_float_args_set(color, 1.0f, 1.0f, 1.0f, alpha);
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_ACTIVE;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
else {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
if (tree_element_active(C, scene, view_layer, soops, te, OL_SETSEL_NONE, false)) {
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
rgba_float_args_set(color, 0.85f, 0.85f, 1.0f, alpha);
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
active = OL_DRAWSEL_ACTIVE;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
}
else {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
active = tree_element_type_active(C, scene, view_layer, soops, te, tselem, OL_SETSEL_NONE, false);
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
rgba_float_args_set(color, 0.85f, 0.85f, 1.0f, alpha);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
/* active circle */
Code Cleanup: outliner used magic numbers for active items and selecting Replace with enums to make it more obvious whats happening
2014-01-16 20:22:45 +11:00
if (active != OL_DRAWSEL_NONE) {
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_draw_roundbox_corner_set(UI_CNR_ALL);
OpenGL: refactor UI_draw_roundbox functions Each function takes a bool (filled vs outline) and a color. We already had multiple ways of passing color in; these are still here. Special variant for anti-aliasing. - took GLenum out of interface - removed UI_RB_ALPHA flag (only one place really used it) - use exact vertex count - removed redundant state changes (BLEND, LINE_SMOOTH)
2017-04-06 19:15:26 -04:00
UI_draw_roundbox_aa(
true,
Various icon adjustments
2017-03-17 16:47:19 +03:00
(float)startx + UI_UNIT_X + 1.0f * ufac,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
(float)*starty + 1.0f * ufac,
Various icon adjustments
2017-03-17 16:47:19 +03:00
(float)startx + 2.0f * UI_UNIT_X - 1.0f * ufac,
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
(float)*starty + UI_UNIT_Y - 1.0f * ufac,
blender 2.8: Opengl: UI_draw_roundbox all is in the title too.. Reviewers: merwin Reviewed By: merwin Subscribers: Blendify, Severin Tags: #bf_blender_2.8, #opengl_gfx Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2337
2016-11-14 20:04:59 -05:00
UI_UNIT_Y / 2.0f - 1.0f * ufac, color);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
glEnable(GL_BLEND); /* roundbox disables it */
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
te->flag |= TE_ACTIVE; // for lookup in display hierarchies
}
Outliner Filtering System + Cleanup User notes: The outliner so far was a great system to handle the object oriented workflow we had in Blender prior to 2.8. However with the introduction of collections the bloated ammount of data we were exposed at a given time was eventually getting on the way of fully utilizing the outliner to manage collections and their objects. We hope that with this filtering system the user can put together the outliner with whichever options he or she seem fit for a given task. Features: * Collection filter: In case users are only focused on objects. * Object filter: Allow users to focus on collections only. * (Object) content filter: Modifiers, mesh, contrainst, materials, ... * (Object) children filter: Hide object children [1]. * Object State (visible, active, selected). * Compact header: hide search options under a search toggle. * Preserve scrolling position before/after filtering [2]. [1] - Note we still need to be able to tell if a children of an object is in a collection, or if the parent object is the only one in the collection. This in fact was one of the first motivations for this patch. But it is to be addressed separately now that we can at least hide children away. [2] - We look at the top-most collection in the outliner, and try to find it again after the filtering and make sure it is in the same position as before. This works nice now. But to work REALLY, REALLY nice we need to also store the previous filter options to be sure the element we try to keep on top was valid for both old and new filters. I would rather do this later though since this smell a lot like feature creeping ;) Remove no longer needed display options: * Current Scene (replaced by View Layer/Collections) * Visible (replaced by filter) * Selected (same) * Active (same) * Same Type (same-ish) How about All Scenes? I have a patch that will come next to replace the current behaviour and focus only on compositing. So basically stop showing the objects and show only view layers, their passes and collections, besides freestyle. Also, while at this I'm also reorganizing the menu to keep View Layer and Collections on top. Developer notes: * Unlike the per-object filtering, for collections we need to filter at tree creation time, to prevent duplication of objects in the outliner. Acknowledgements: Thanks Pablo Vazquez for helping testing, thinking some design questions together and pushing this to its final polished state as you see here. Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a final review pass after I addressed his concerns. So blame is on me for any issue I may be introducing here. Sergey was the author of the "preserve scrolling position" idea. I'm happy with how it is working, thank you. Reviewers: sergey, Severin, venomgfx Subscribers: lichtwerk, duarteframos Differential Revision: https://developer.blender.org/D2992
2018-01-19 11:39:54 -02:00
if ((soops->outlinevis == SO_COLLECTIONS) && (tselem->type == TSE_SCENE_COLLECTION) && (te->parent == NULL)) {
Outliner: Master Collection always expanded This is part of T53495. This makes sure the master collection is always expanded and you don't even get the expand/collapse icons for it. This is only for the Collecions (currently Master Collection Tree) option, not for active view layer.
2018-01-02 14:00:03 -02:00
/* Master collection can't expand/collapse. */
}
else if (te->subtree.first || (tselem->type == 0 && te->idcode == ID_SCE) || (te->flag & TE_LAZY_CLOSED)) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* open/close icon, only when sublevels, except for scene */
int icon_x;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
if (tselem->type == 0 && ELEM(te->idcode, ID_OB, ID_SCE))
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
icon_x = startx;
else
style cleanup: outliner
2012-05-07 17:56:30 +00:00
icon_x = startx + 5 * ufac;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
// icons a bit higher
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops))
Merge branch 'master' into blender2.8 Conflicts: source/blender/editors/space_outliner/outliner_draw.c
2017-03-17 15:34:35 +01:00
UI_icon_draw_alpha((float)icon_x + 2 * ufac, (float)*starty + 1 * ufac, ICON_DISCLOSURE_TRI_DOWN,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
alpha_fac);
Patch [#23443] Change outliner filter into search Shane Ambler (sambler) for this 12-month vintage! From description: One thing with the outliner filter box is it only filters items that are currently visible. To find what you want you need to manually expand a few levels so that what you want to find is visible. This small patch expands items when filtering is done - effectively turning it into a search. Currently this does not alter the datablocks view as expanding all entries takes waaaay tooooo long. I prevent the expansion of RNA entries for userprefs which prevents infinite recursion but the datablocks list is just too big for this approach. I think it would need a custom outliner_build_tree for a full search.
2011-09-09 12:46:07 +00:00
else
Merge branch 'master' into blender2.8 Conflicts: source/blender/editors/space_outliner/outliner_draw.c
2017-03-17 15:34:35 +01:00
UI_icon_draw_alpha((float)icon_x + 2 * ufac, (float)*starty + 1 * ufac, ICON_DISCLOSURE_TRI_RIGHT,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
alpha_fac);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
offsx += UI_UNIT_X;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* datatype icon */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (!(ELEM(tselem->type, TSE_RNA_PROPERTY, TSE_RNA_ARRAY_ELEM))) {
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
tselem_draw_icon(block, xmax, (float)startx + offsx, (float)*starty, tselem, te, alpha_fac);
Various icon adjustments
2017-03-17 16:47:19 +03:00
offsx += UI_UNIT_X + 2 * ufac;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
else
style cleanup: outliner
2012-05-07 17:56:30 +00:00
offsx += 2 * ufac;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Rename ID_IS_LINKED_DATABLOCK to ID_IS_LINKED. This makes code closer to id_override/assent-engine ones, which introduce a new type of linked data, and hence reserve ID_IS_LINKED_DATABLOCK to real linked datablocks.
2017-11-06 17:17:10 +01:00
if (tselem->type == 0 && ID_IS_LINKED(tselem->id)) {
Split id->flag in two, persistent flags and runtime tags. This is purely internal sanitizing/cleanup, no change in behavior is expected at all. This change was also needed because we were getting short on ID flags, and future enhancement of 'user_one' ID behavior requires two new ones. id->flag remains for persistent data (fakeuser only, so far!), this also allows us 100% backward & forward compatibility. New id->tag is used for most flags. Though written in .blend files, its content is cleared at read time. Note that .blend file version was bumped, so that we can clear runtimeflags from old .blends, important in case we add new persistent flags in future. Also, behavior of tags (either status ones, or whether they need to be cleared before/after use) has been added as comments to their declaration. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
if (tselem->id->tag & LIB_TAG_MISSING) {
Merge branch 'master' into blender2.8 Conflicts: source/blender/editors/space_outliner/outliner_draw.c
2017-03-17 15:34:35 +01:00
UI_icon_draw_alpha((float)startx + offsx + 2 * ufac, (float)*starty + 2 * ufac, ICON_LIBRARY_DATA_BROKEN,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
alpha_fac);
First step to handle missing libs/datablocks when reading a file. Idea is, instead of ignoring completely missing linked datablocks, to create void placeholders for them. That way, you can work on your file, save it, and find again your missing data once lib becomes available again. Or you can edit missing lib's path (in Outliner), save and reload the file, and you are done. Also, Outliner now shows broken libraries (and placeholders) with a 'broken lib' icon. Future plans are also to be able to relocate missing libs and reload them at runtime. Code notes: - Placeholder ID is just a regular datablock of same type as expected linked one, with 'default' data, and a LIB_MISSING bitflag set. - To allow creation of such datablocks, creation of datablocks in BKE was split in two step: + Allocation of memory itself. + Setting of all internal data to default values. See also the design task (T43351). Reviewed by @campbellbarton, thanks a bunch! Differential Revision: https://developer.blender.org/D1394
2015-10-20 14:44:57 +02:00
}
Split id->flag in two, persistent flags and runtime tags. This is purely internal sanitizing/cleanup, no change in behavior is expected at all. This change was also needed because we were getting short on ID flags, and future enhancement of 'user_one' ID behavior requires two new ones. id->flag remains for persistent data (fakeuser only, so far!), this also allows us 100% backward & forward compatibility. New id->tag is used for most flags. Though written in .blend files, its content is cleared at read time. Note that .blend file version was bumped, so that we can clear runtimeflags from old .blends, important in case we add new persistent flags in future. Also, behavior of tags (either status ones, or whether they need to be cleared before/after use) has been added as comments to their declaration. Reviewers: sergey, campbellbarton Differential Revision: https://developer.blender.org/D1683
2015-12-27 11:53:50 +01:00
else if (tselem->id->tag & LIB_TAG_INDIRECT) {
Merge branch 'master' into blender2.8 Conflicts: source/blender/editors/space_outliner/outliner_draw.c
2017-03-17 15:34:35 +01:00
UI_icon_draw_alpha((float)startx + offsx + 2 * ufac, (float)*starty + 2 * ufac, ICON_LIBRARY_DATA_INDIRECT,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
alpha_fac);
First step to handle missing libs/datablocks when reading a file. Idea is, instead of ignoring completely missing linked datablocks, to create void placeholders for them. That way, you can work on your file, save it, and find again your missing data once lib becomes available again. Or you can edit missing lib's path (in Outliner), save and reload the file, and you are done. Also, Outliner now shows broken libraries (and placeholders) with a 'broken lib' icon. Future plans are also to be able to relocate missing libs and reload them at runtime. Code notes: - Placeholder ID is just a regular datablock of same type as expected linked one, with 'default' data, and a LIB_MISSING bitflag set. - To allow creation of such datablocks, creation of datablocks in BKE was split in two step: + Allocation of memory itself. + Setting of all internal data to default values. See also the design task (T43351). Reviewed by @campbellbarton, thanks a bunch! Differential Revision: https://developer.blender.org/D1394
2015-10-20 14:44:57 +02:00
}
else {
Merge branch 'master' into blender2.8 Conflicts: source/blender/editors/space_outliner/outliner_draw.c
2017-03-17 15:34:35 +01:00
UI_icon_draw_alpha((float)startx + offsx + 2 * ufac, (float)*starty + 2 * ufac, ICON_LIBRARY_DATA_DIRECT,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
alpha_fac);
First step to handle missing libs/datablocks when reading a file. Idea is, instead of ignoring completely missing linked datablocks, to create void placeholders for them. That way, you can work on your file, save it, and find again your missing data once lib becomes available again. Or you can edit missing lib's path (in Outliner), save and reload the file, and you are done. Also, Outliner now shows broken libraries (and placeholders) with a 'broken lib' icon. Future plans are also to be able to relocate missing libs and reload them at runtime. Code notes: - Placeholder ID is just a regular datablock of same type as expected linked one, with 'default' data, and a LIB_MISSING bitflag set. - To allow creation of such datablocks, creation of datablocks in BKE was split in two step: + Allocation of memory itself. + Setting of all internal data to default values. See also the design task (T43351). Reviewed by @campbellbarton, thanks a bunch! Differential Revision: https://developer.blender.org/D1394
2015-10-20 14:44:57 +02:00
}
Various icon adjustments
2017-03-17 16:47:19 +03:00
offsx += UI_UNIT_X + 2 * ufac;
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
Add override icon to such data-blocks in OUtliner.
2017-12-18 12:02:23 +01:00
else if (tselem->type == 0 && ID_IS_STATIC_OVERRIDE(tselem->id)) {
UI_icon_draw_alpha((float)startx + offsx + 2 * ufac, (float)*starty + 2 * ufac, ICON_LIBRARY_DATA_OVERRIDE,
alpha_fac);
offsx += UI_UNIT_X + 2 * ufac;
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
glDisable(GL_BLEND);
/* name */
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
if ((tselem->flag & TSE_TEXTBUT) == 0) {
Remove most (maybe all?) remaining yellow text Decided to request the text color as argument for UI_fonstyle_draw functions, rather than keeping it being another state to keep track of.
2017-02-10 00:00:21 +01:00
unsigned char text_col[4];
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
if (active == OL_DRAWSEL_NORMAL) {
Remove most (maybe all?) remaining yellow text Decided to request the text color as argument for UI_fonstyle_draw functions, rather than keeping it being another state to keep track of.
2017-02-10 00:00:21 +01:00
UI_GetThemeColor4ubv(TH_TEXT_HI, text_col);
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
}
else if (ELEM(tselem->type, TSE_RNA_PROPERTY, TSE_RNA_ARRAY_ELEM)) {
Remove most (maybe all?) remaining yellow text Decided to request the text color as argument for UI_fonstyle_draw functions, rather than keeping it being another state to keep track of.
2017-02-10 00:00:21 +01:00
UI_GetThemeColorBlend3ubv(TH_BACK, TH_TEXT, 0.75f, text_col);
text_col[3] = 255;
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
}
else {
Remove most (maybe all?) remaining yellow text Decided to request the text color as argument for UI_fonstyle_draw functions, rather than keeping it being another state to keep track of.
2017-02-10 00:00:21 +01:00
UI_GetThemeColor4ubv(TH_TEXT, text_col);
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
text_col[3] *= alpha_fac;
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
Remove most (maybe all?) remaining yellow text Decided to request the text color as argument for UI_fonstyle_draw functions, rather than keeping it being another state to keep track of.
2017-02-10 00:00:21 +01:00
UI_fontstyle_draw_simple(fstyle, startx + offsx, *starty + 5 * ufac, te->name, text_col);
Fix T48654: outline text visible while renaming Both button and rename text would draw while renaming, caused issues with some themes.
2016-06-15 21:46:32 +10:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
offsx += (int)(UI_UNIT_X + UI_fontstyle_string_width(fstyle, te->name));
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* closed item, we draw the icons, not when it's a scene, or master-server list though */
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (!TSELEM_OPEN(tselem, soops)) {
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (te->subtree.first) {
style cleanup: if();
2012-10-07 09:48:59 +00:00
if (tselem->type == 0 && te->idcode == ID_SCE) {
/* pass */
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
/* this tree element always has same amount of branches, so don't draw */
style cleanup: if();
2012-10-07 09:48:59 +00:00
else if (tselem->type != TSE_R_LAYER) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
int tempx = startx + offsx;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
glEnable(GL_BLEND);
style cleanup: if();
2012-10-07 09:48:59 +00:00
/* divider */
OpenGL: outliner_draw_tree_element uses new imm mode D2438 by @cyrax review by @merwin part of T49043
2017-02-08 18:35:56 -05:00
{
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_I32, 2, GWN_FETCH_INT_TO_FLOAT);
OpenGL: outliner_draw_tree_element uses new imm mode D2438 by @cyrax review by @merwin part of T49043
2017-02-08 18:35:56 -05:00
unsigned char col[4];
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
OpenGL: outliner_draw_tree_element uses new imm mode D2438 by @cyrax review by @merwin part of T49043
2017-02-08 18:35:56 -05:00
UI_GetThemeColorShade4ubv(TH_BACK, -40, col);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
col[3] *= alpha_fac;
OpenGL: outliner_draw_tree_element uses new imm mode D2438 by @cyrax review by @merwin part of T49043
2017-02-08 18:35:56 -05:00
immUniformColor4ubv(col);
immRecti(pos, tempx - 10.0f * ufac,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
*starty + 4.0f * ufac,
tempx - 8.0f * ufac,
*starty + UI_UNIT_Y - 4.0f * ufac);
OpenGL: outliner_draw_tree_element uses new imm mode D2438 by @cyrax review by @merwin part of T49043
2017-02-08 18:35:56 -05:00
immUnbindProgram();
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
outliner_draw_iconrow(C, block, scene, view_layer, soops, &te->subtree, 0, xmax, &tempx,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
*starty, alpha_fac);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
glDisable(GL_BLEND);
}
}
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* store coord and continue, we need coordinates for elements outside view too */
Remove superfluous iterations (caused by typo) and type casts in outliner This significantly lowers the position of outliner_draw_tree_element in profiler and partially fixes [#36260] (2,300 Objects Makes Blender Unresponsive)
2013-07-30 08:45:45 +00:00
te->xs = startx;
te->ys = *starty;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
te->xend = startx + offsx;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops)) {
style cleanup: outliner
2012-05-07 17:56:30 +00:00
*starty -= UI_UNIT_Y;
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
for (TreeElement *ten = te->subtree.first; ten; ten = ten->next) {
/* check if element needs to be drawn grayed out, but also gray out
* childs of a grayed out parent (pass on draw_grayed_out to childs) */
bool draw_childs_grayed_out = draw_grayed_out || (ten->drag_data != NULL);
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
outliner_draw_tree_element(C, block, fstyle, scene, view_layer, ar, soops, ten, draw_childs_grayed_out,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
startx + UI_UNIT_X, starty, te_edit, te_floating);
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
else {
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
for (TreeElement *ten = te->subtree.first; ten; ten = ten->next) {
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
outliner_set_coord_tree_element(ten, startx, *starty);
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
*starty -= UI_UNIT_Y;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Support drag & drop of collections across multiple hierarchy levels Two issues are remaining, they'll be fixed separately: * Graphical feedback when dragging within the master collection is wrong * There's some bug where collections swap places instead, Dalai will investigate
2017-03-10 15:03:06 +01:00
static void outliner_draw_tree_element_floating(
const ARegion *ar, const TreeElement *te_floating)
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
{
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
const TreeElement *te_insert = te_floating->drag_data->insert_handle;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
const int line_width = 2;
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
unsigned int pos = GWN_vertformat_attr_add(immVertexFormat(), "pos", GWN_COMP_F32, 2, GWN_FETCH_FLOAT);
Support drag & drop of collections across multiple hierarchy levels Two issues are remaining, they'll be fixed separately: * Graphical feedback when dragging within the master collection is wrong * There's some bug where collections swap places instead, Dalai will investigate
2017-03-10 15:03:06 +01:00
int coord_y = te_insert->ys;
Draw drag&drop feedback overlays with element indentation That way users can see better at which hierarchy level the element will be inserted into.
2017-03-10 15:58:08 +01:00
int coord_x = te_insert->xs;
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
float col[4];
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
if (te_insert == te_floating) {
/* don't draw anything */
return;
}
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
UI_GetThemeColorShade4fv(TH_BACK, -40, col);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
glEnable(GL_BLEND);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
Support drag & drop of collections across multiple hierarchy levels Two issues are remaining, they'll be fixed separately: * Graphical feedback when dragging within the master collection is wrong * There's some bug where collections swap places instead, Dalai will investigate
2017-03-10 15:03:06 +01:00
if (ELEM(te_floating->drag_data->insert_type, TE_INSERT_BEFORE, TE_INSERT_AFTER)) {
if (te_floating->drag_data->insert_type == TE_INSERT_BEFORE) {
coord_y += UI_UNIT_Y;
}
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
immUniformColor4fv(col);
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
glLineWidth(line_width);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
immBegin(GWN_PRIM_LINE_STRIP, 2);
Draw drag&drop feedback overlays with element indentation That way users can see better at which hierarchy level the element will be inserted into.
2017-03-10 15:58:08 +01:00
immVertex2f(pos, coord_x, coord_y);
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
immVertex2f(pos, ar->v2d.cur.xmax, coord_y);
immEnd();
}
else {
BLI_assert(te_floating->drag_data->insert_type == TE_INSERT_INTO);
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
immUniformColor3fvAlpha(col, col[3] * 0.5f);
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
immBegin(GWN_PRIM_TRI_STRIP, 4);
Draw drag&drop feedback overlays with element indentation That way users can see better at which hierarchy level the element will be inserted into.
2017-03-10 15:58:08 +01:00
immVertex2f(pos, coord_x, coord_y + UI_UNIT_Y);
OpenGL / Outliner: QUADS are not supported in core
2017-04-07 16:42:56 +02:00
immVertex2f(pos, coord_x, coord_y);
Get UI ready for using drag & drop to nest a collection into another one Nothing happen yet when it's supposed to insert the collection into another one, that part will be handled by @dfelinto. See gif for demo of how it works UI wise: {F500337} Also fixed off-by-one error in utility function.
2017-03-02 17:11:09 +01:00
immVertex2f(pos, ar->v2d.cur.xmax, coord_y + UI_UNIT_Y);
immVertex2f(pos, ar->v2d.cur.xmax, coord_y);
immEnd();
}
glDisable(GL_BLEND);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
immUnbindProgram();
}
static void outliner_draw_hierarchy_lines_recursive(unsigned pos, SpaceOops *soops, ListBase *lb, int startx,
const unsigned char col[4], bool draw_grayed_out,
int *starty)
{
Fix T53764: vertical line glitch for collections with objects and collections The code for vertical line was assuming that we necessarily neeeded vertical lines for all the elements. Which is not true since we are not drawing vertical and horizontal lines for collections. Patch made in contribution with Philippe Schmid (@Quetzal).
2018-01-11 17:17:17 -02:00
TreeElement *te, *te_vertical_line_last = NULL;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
TreeStoreElem *tselem;
int y1, y2;
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
if (BLI_listbase_is_empty(lb)) {
return;
}
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
const unsigned char grayed_alpha = col[3] / 2;
Fix T53764: vertical line glitch for collections with objects and collections The code for vertical line was assuming that we necessarily neeeded vertical lines for all the elements. Which is not true since we are not drawing vertical and horizontal lines for collections. Patch made in contribution with Philippe Schmid (@Quetzal).
2018-01-11 17:17:17 -02:00
/* For vertical lines between objects. */
y1 = *starty;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (te = lb->first; te; te = te->next) {
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
bool draw_childs_grayed_out = draw_grayed_out || (te->drag_data != NULL);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
tselem = TREESTORE(te);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
if (draw_childs_grayed_out) {
immUniformColor3ubvAlpha(col, grayed_alpha);
}
else {
immUniformColor4ubv(col);
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
Fix T53764: vertical line glitch for collections with objects and collections The code for vertical line was assuming that we necessarily neeeded vertical lines for all the elements. Which is not true since we are not drawing vertical and horizontal lines for collections. Patch made in contribution with Philippe Schmid (@Quetzal).
2018-01-11 17:17:17 -02:00
/* Horizontal Line? */
if (tselem->type == 0 && (te->idcode == ID_OB || te->idcode == ID_SCE)) {
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
immRecti(pos, startx, *starty, startx + UI_UNIT_X, *starty - 1);
Fix T53764: vertical line glitch for collections with objects and collections The code for vertical line was assuming that we necessarily neeeded vertical lines for all the elements. Which is not true since we are not drawing vertical and horizontal lines for collections. Patch made in contribution with Philippe Schmid (@Quetzal).
2018-01-11 17:17:17 -02:00
/* Vertical Line? */
if (te->idcode == ID_OB) {
te_vertical_line_last = te;
y2 = *starty;
}
}
style cleanup: outliner
2012-05-07 17:56:30 +00:00
*starty -= UI_UNIT_Y;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops))
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
outliner_draw_hierarchy_lines_recursive(pos, soops, &te->subtree, startx + UI_UNIT_X,
col, draw_childs_grayed_out, starty);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
cleanup use of immUniformColor - use best function for the job - don't specify alpha if 100% - 'f' for floating point literals
2017-04-16 13:44:34 -04:00
if (draw_grayed_out) {
immUniformColor3ubvAlpha(col, grayed_alpha);
}
else {
immUniformColor4ubv(col);
}
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
Fix T53764: vertical line glitch for collections with objects and collections The code for vertical line was assuming that we necessarily neeeded vertical lines for all the elements. Which is not true since we are not drawing vertical and horizontal lines for collections. Patch made in contribution with Philippe Schmid (@Quetzal).
2018-01-11 17:17:17 -02:00
/* Vertical line. */
te = te_vertical_line_last;
if ((te != NULL) && (te->parent || lb->first != lb->last)) {
immRecti(pos, startx, y1 + UI_UNIT_Y, startx + 1, y2);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
static void outliner_draw_hierarchy_lines(SpaceOops *soops, ListBase *lb, int startx, int *starty)
{
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_I32, 2, GWN_FETCH_INT_TO_FLOAT);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
unsigned char col[4];
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
UI_GetThemeColorBlend3ubv(TH_BACK, TH_TEXT, 0.4f, col);
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
col[3] = 255;
glEnable(GL_BLEND);
outliner_draw_hierarchy_lines_recursive(pos, soops, lb, startx, col, false, starty);
glDisable(GL_BLEND);
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
immUnbindProgram();
}
Cleanup: Unused parameters in Outliner These were only passed to own recursion calls.
2016-10-16 15:19:18 +02:00
static void outliner_draw_struct_marks(ARegion *ar, SpaceOops *soops, ListBase *lb, int *starty)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
TreeElement *te;
TreeStoreElem *tselem;
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
for (te = lb->first; te; te = te->next) {
tselem = TREESTORE(te);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* selection status */
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops))
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
if (tselem->type == TSE_RNA_STRUCT) {
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_I32, 2, GWN_FETCH_INT_TO_FLOAT);
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
immThemeColorShadeAlpha(TH_BACK, -15, -200);
immRecti(pos, 0, *starty + 1, (int)ar->v2d.cur.xmax, *starty + UI_UNIT_Y - 1);
immUnbindProgram();
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
*starty -= UI_UNIT_Y;
style cleanup: whitespace / commas
2012-04-29 15:47:02 +00:00
if (TSELEM_OPEN(tselem, soops)) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
outliner_draw_struct_marks(ar, soops, &te->subtree, starty);
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
if (tselem->type == TSE_RNA_STRUCT) {
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_F32, 2, GWN_FETCH_FLOAT);
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
immThemeColorShadeAlpha(TH_BACK, -15, -200);
OpenGl immediate mode: remove imm_draw_line Replaced all calls to `imm_draw_line` by plain `immVertex2f` calls, and removed `imm_draw_line`, as that function was not supposed to exist in the first place, and causes unnecessary calls to `immBegin`/`immEnd`. Part of T49043
2017-02-23 02:52:36 -03:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
immBegin(GWN_PRIM_LINES, 2);
OpenGl immediate mode: remove imm_draw_line Replaced all calls to `imm_draw_line` by plain `immVertex2f` calls, and removed `imm_draw_line`, as that function was not supposed to exist in the first place, and causes unnecessary calls to `immBegin`/`immEnd`. Part of T49043
2017-02-23 02:52:36 -03:00
immVertex2f(pos, 0, (float)*starty + UI_UNIT_Y);
immVertex2f(pos, ar->v2d.cur.xmax, (float)*starty + UI_UNIT_Y);
immEnd();
Updating outliner_draw_struct_marks to retained mode Had to add a few utility functions to replace existing functions. Let me know if these are duplicates. Reviewers: merwin Reviewed By: merwin Tags: #bf_blender_2.8 Maniphest Tasks: T49043 Differential Revision: https://developer.blender.org/D2434
2017-01-15 19:26:35 -05:00
immUnbindProgram();
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
}
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
static void outliner_draw_highlights_recursive(
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
unsigned pos, const ARegion *ar, const SpaceOops *soops, const ListBase *lb,
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
const float col_selection[4], const float col_highlight[4], const float col_searchmatch[4],
int start_x, int *io_start_y)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
const bool is_searching = SEARCHING_OUTLINER(soops) ||
Outliner Filtering System + Cleanup User notes: The outliner so far was a great system to handle the object oriented workflow we had in Blender prior to 2.8. However with the introduction of collections the bloated ammount of data we were exposed at a given time was eventually getting on the way of fully utilizing the outliner to manage collections and their objects. We hope that with this filtering system the user can put together the outliner with whichever options he or she seem fit for a given task. Features: * Collection filter: In case users are only focused on objects. * Object filter: Allow users to focus on collections only. * (Object) content filter: Modifiers, mesh, contrainst, materials, ... * (Object) children filter: Hide object children [1]. * Object State (visible, active, selected). * Compact header: hide search options under a search toggle. * Preserve scrolling position before/after filtering [2]. [1] - Note we still need to be able to tell if a children of an object is in a collection, or if the parent object is the only one in the collection. This in fact was one of the first motivations for this patch. But it is to be addressed separately now that we can at least hide children away. [2] - We look at the top-most collection in the outliner, and try to find it again after the filtering and make sure it is in the same position as before. This works nice now. But to work REALLY, REALLY nice we need to also store the previous filter options to be sure the element we try to keep on top was valid for both old and new filters. I would rather do this later though since this smell a lot like feature creeping ;) Remove no longer needed display options: * Current Scene (replaced by View Layer/Collections) * Visible (replaced by filter) * Selected (same) * Active (same) * Same Type (same-ish) How about All Scenes? I have a patch that will come next to replace the current behaviour and focus only on compositing. So basically stop showing the objects and show only view layers, their passes and collections, besides freestyle. Also, while at this I'm also reorganizing the menu to keep View Layer and Collections on top. Developer notes: * Unlike the per-object filtering, for collections we need to filter at tree creation time, to prevent duplication of objects in the outliner. Acknowledgements: Thanks Pablo Vazquez for helping testing, thinking some design questions together and pushing this to its final polished state as you see here. Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a final review pass after I addressed his concerns. So blame is on me for any issue I may be introducing here. Sergey was the author of the "preserve scrolling position" idea. I'm happy with how it is working, thank you. Reviewers: sergey, Severin, venomgfx Subscribers: lichtwerk, duarteframos Differential Revision: https://developer.blender.org/D2992
2018-01-19 11:39:54 -02:00
(soops->outlinevis == SO_DATABLOCKS &&
(soops->filter & SO_FILTER_SEARCH) &&
soops->search_string[0] != 0);
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
for (TreeElement *te = lb->first; te; te = te->next) {
const TreeStoreElem *tselem = TREESTORE(te);
const int start_y = *io_start_y;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* selection status */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:38:07 +00:00
if (tselem->flag & TSE_SELECTED) {
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
immUniformColor4fv(col_selection);
immRecti(pos, 0, start_y + 1, (int)ar->v2d.cur.xmax, start_y + UI_UNIT_Y - 1);
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
}
/* search match highlights
* we don't expand items when searching in the datablocks but we
* still want to highlight any filter matches. */
if (is_searching && (tselem->flag & TSE_SEARCHMATCH)) {
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
immUniformColor4fv(col_searchmatch);
immRecti(pos, start_x, start_y + 1, ar->v2d.cur.xmax, start_y + UI_UNIT_Y - 1);
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
}
/* mouse hover highlights */
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
if ((tselem->flag & TSE_HIGHLIGHTED) || (te->drag_data != NULL)) {
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
immUniformColor4fv(col_highlight);
immRecti(pos, 0, start_y + 1, (int)ar->v2d.cur.xmax, start_y + UI_UNIT_Y - 1);
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
}
*io_start_y -= UI_UNIT_Y;
if (TSELEM_OPEN(tselem, soops)) {
outliner_draw_highlights_recursive(
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
pos, ar, soops, &te->subtree, col_selection, col_highlight, col_searchmatch,
start_x + UI_UNIT_X, io_start_y);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
}
}
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
static void outliner_draw_highlights(ARegion *ar, SpaceOops *soops, int startx, int *starty)
{
const float col_highlight[4] = {1.0f, 1.0f, 1.0f, 0.13f};
float col_selection[4], col_searchmatch[4];
UI_GetThemeColor3fv(TH_SELECT_HIGHLIGHT, col_selection);
col_selection[3] = 1.0f; /* no alpha */
UI_GetThemeColor4fv(TH_MATCH, col_searchmatch);
col_searchmatch[3] = 0.5f;
glEnable(GL_BLEND);
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_I32, 2, GWN_FETCH_INT_TO_FLOAT);
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
outliner_draw_highlights_recursive(pos, ar, soops, &soops->tree, col_selection, col_highlight, col_searchmatch,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
startx, starty);
OpenGL: outliner_draw_highlights uses new imm mode Patch D2433 by @cyrax, part of T49043 reviewed by @merwin
2017-02-07 12:50:04 -05:00
immUnbindProgram();
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
glDisable(GL_BLEND);
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
static void outliner_draw_tree(
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
bContext *C, uiBlock *block, Scene *scene, ViewLayer *view_layer, ARegion *ar,
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
SpaceOops *soops, const bool has_restrict_icons,
TreeElement **te_edit)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
UI: cleanup UI_fontstyle_string_width, UI_draw_string Both were maked as temp, but used often. Now pass uiFontStyle to both, rename UI_draw_string to UI_fontstyle_draw_simple, since its a variant of UI_fontstyle_draw that skips shadow, align... etc.
2015-01-20 14:25:39 +11:00
const uiFontStyle *fstyle = UI_FSTYLE_WIDGET;
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
TreeElement *te_floating = NULL;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
int starty, startx;
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); // only once
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
if (soops->outlinevis == SO_DATABLOCKS) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* struct marks */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
starty = (int)ar->v2d.tot.ymax - UI_UNIT_Y - OL_Y_OFFSET;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
outliner_draw_struct_marks(ar, soops, &soops->tree, &starty);
}
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
/* draw highlights before hierarchy */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
starty = (int)ar->v2d.tot.ymax - UI_UNIT_Y - OL_Y_OFFSET;
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
startx = 0;
outliner_draw_highlights(ar, soops, startx, &starty);
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
/* set scissor so tree elements or lines can't overlap restriction icons */
GLfloat scissor[4] = {0};
if (has_restrict_icons) {
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
int mask_x = BLI_rcti_size_x(&ar->v2d.mask) - (int)OL_TOGW + 1;
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
CLAMP_MIN(mask_x, 0);
glGetFloatv(GL_SCISSOR_BOX, scissor);
glScissor(ar->winrct.xmin, ar->winrct.ymin, mask_x, ar->winy);
}
More spell and typo fixes (mostly visualise->visualize, grey->gray, normalise->normalize).
2012-07-03 19:09:07 +00:00
// gray hierarchy lines
Update outliner_draw_hierarchy_lines to use new imm mode Patch D2437 by @cyrax review by @merwin
2017-02-08 15:02:43 -05:00
style cleanup: outliner
2012-05-07 17:56:30 +00:00
starty = (int)ar->v2d.tot.ymax - UI_UNIT_Y / 2 - OL_Y_OFFSET;
startx = 6;
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
outliner_draw_hierarchy_lines(soops, &soops->tree, startx, &starty);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
// items themselves
style cleanup: outliner
2012-05-07 17:56:30 +00:00
starty = (int)ar->v2d.tot.ymax - UI_UNIT_Y - OL_Y_OFFSET;
startx = 0;
Outliner: Element mouse hover feedback Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted. This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
2016-10-15 00:40:33 +02:00
for (TreeElement *te = soops->tree.first; te; te = te->next) {
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
outliner_draw_tree_element(C, block, fstyle, scene, view_layer, ar, soops, te, te->drag_data != NULL,
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
startx, &starty, te_edit, &te_floating);
}
Improve outliner drag&drop feedback by using drop poll callbacks This way we can ensure the overlay to indicate where the item would be placed if it was dropped now is always at the correct place and doesn't mislead the user.
2017-03-10 17:05:50 +01:00
if (te_floating && te_floating->drag_data->insert_handle) {
Support drag & drop of collections across multiple hierarchy levels Two issues are remaining, they'll be fixed separately: * Graphical feedback when dragging within the master collection is wrong * There's some bug where collections swap places instead, Dalai will investigate
2017-03-10 15:03:06 +01:00
outliner_draw_tree_element_floating(ar, te_floating);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
if (has_restrict_icons) {
/* reset scissor */
glScissor(UNPACK4(scissor));
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
static void outliner_back(ARegion *ar)
{
int ystart;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
ystart = (int)ar->v2d.tot.ymax;
ystart = UI_UNIT_Y * (ystart / (UI_UNIT_Y)) - OL_Y_OFFSET;
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
Gwn_VertFormat *format = immVertexFormat();
unsigned int pos = GWN_vertformat_attr_add(format, "pos", GWN_COMP_F32, 2, GWN_FETCH_FLOAT);
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
immUniformThemeColorShade(TH_BACK, 6);
const float x1 = 0.0f, x2 = ar->v2d.cur.xmax;
float y1 = ystart, y2;
int tot = (int)floor(ystart - ar->v2d.cur.ymin + 2 * UI_UNIT_Y) / (2 * UI_UNIT_Y);
if (tot > 0) {
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
immBegin(GWN_PRIM_TRIS, 6 * tot);
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
while (tot--) {
y1 -= 2 * UI_UNIT_Y;
y2 = y1 + UI_UNIT_Y;
immVertex2f(pos, x1, y1);
immVertex2f(pos, x2, y1);
immVertex2f(pos, x2, y2);
First batch of PRIM_QUAD_XXX replacement by PRIM_TRIANGLES.
2017-04-10 15:16:59 +02:00
immVertex2f(pos, x1, y1);
immVertex2f(pos, x2, y2);
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
immVertex2f(pos, x1, y2);
}
immEnd();
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
immediate mode: outliner background I tried using immRecti instead, but it didn't work. The current approach should be more efficient anyways (since GL_TRIANGLE_FAN wouldn't work here).
2016-10-20 01:43:46 +00:00
immUnbindProgram();
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
static void outliner_draw_restrictcols(ARegion *ar)
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
{
UI: Support drag & drop reordering of collections This adds initial support for reordering collections from the Outliner using drag & drop. Although drag & drop support is limited to collections for now, this lays most foundations for general drag & drop reordering support in the Outliner. There are some design questions to be answered though: * Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?) * Should/can we allow mixing of different data types? (e.g. mixing render layers with objects) * How could we realize this technically? Notes: * "Sort Alphabetically" has to be disabled to use this ("View" menu). * Reordering only works with collections on the same hierarchy level. * Added some visual feedback that should work quite well, it's by far not a final design though: {F493806} * Modified collection orders are stored in .blends. * Reordering can be undone. * Did minor cleanups here and there.
2017-02-22 16:02:43 +01:00
glLineWidth(1.0f);
OpenGL: remove last uses of sdrawline & sdrawbox Part of T49043
2017-03-03 13:12:29 -05:00
Gawain API naming refactor Use consistent prefix for gawain API names as well as some abbreviations to avoid over-long names, see: D2678
2017-06-19 20:18:04 +10:00
unsigned int pos = GWN_vertformat_attr_add(immVertexFormat(), "pos", GWN_COMP_I32, 2, GWN_FETCH_INT_TO_FLOAT);
OpenGL: remove last uses of sdrawline & sdrawbox Part of T49043
2017-03-03 13:12:29 -05:00
immBindBuiltinProgram(GPU_SHADER_2D_UNIFORM_COLOR);
immUniformThemeColorShadeAlpha(TH_BACK, -15, -200);
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
immBegin(GWN_PRIM_LINES, 6);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), (int)ar->v2d.cur.ymax);
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_VIEWX), (int)ar->v2d.cur.ymin);
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), (int)ar->v2d.cur.ymax);
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_SELECTX), (int)ar->v2d.cur.ymin);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
OpenGL: remove last uses of sdrawline & sdrawbox Part of T49043
2017-03-03 13:12:29 -05:00
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_RENDERX), (int)ar->v2d.cur.ymax);
immVertex2i(pos, (int)(ar->v2d.cur.xmax - OL_TOG_RESTRICT_RENDERX), (int)ar->v2d.cur.ymin);
immEnd();
immUnbindProgram();
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
/* ****************************************************** */
/* Main Entrypoint - Draw contents of Outliner editor */
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
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
void draw_outliner(const bContext *C)
{
Reshuffled data view for Outliner. - The new "Main Data" option is now under the category "Blender File". - That category also displays the Linked Library files. (Including allows browsing what's used from this file) Also fixed CTRL+click on names, crashed.
2012-12-22 16:49:50 +00:00
Main *mainvar = CTX_data_main(C);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
Scene *scene = CTX_data_scene(C);
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
ViewLayer *view_layer = CTX_data_view_layer(C);
style cleanup: outliner
2012-05-07 17:56:30 +00:00
ARegion *ar = CTX_wm_region(C);
View2D *v2d = &ar->v2d;
SpaceOops *soops = CTX_wm_space_outliner(C);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
uiBlock *block;
style cleanup: outliner
2012-05-07 17:56:30 +00:00
int sizey = 0, sizex = 0, sizex_rna = 0;
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
TreeElement *te_edit = NULL;
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
bool has_restrict_icons;
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
Outliner Filtering System + Cleanup User notes: The outliner so far was a great system to handle the object oriented workflow we had in Blender prior to 2.8. However with the introduction of collections the bloated ammount of data we were exposed at a given time was eventually getting on the way of fully utilizing the outliner to manage collections and their objects. We hope that with this filtering system the user can put together the outliner with whichever options he or she seem fit for a given task. Features: * Collection filter: In case users are only focused on objects. * Object filter: Allow users to focus on collections only. * (Object) content filter: Modifiers, mesh, contrainst, materials, ... * (Object) children filter: Hide object children [1]. * Object State (visible, active, selected). * Compact header: hide search options under a search toggle. * Preserve scrolling position before/after filtering [2]. [1] - Note we still need to be able to tell if a children of an object is in a collection, or if the parent object is the only one in the collection. This in fact was one of the first motivations for this patch. But it is to be addressed separately now that we can at least hide children away. [2] - We look at the top-most collection in the outliner, and try to find it again after the filtering and make sure it is in the same position as before. This works nice now. But to work REALLY, REALLY nice we need to also store the previous filter options to be sure the element we try to keep on top was valid for both old and new filters. I would rather do this later though since this smell a lot like feature creeping ;) Remove no longer needed display options: * Current Scene (replaced by View Layer/Collections) * Visible (replaced by filter) * Selected (same) * Active (same) * Same Type (same-ish) How about All Scenes? I have a patch that will come next to replace the current behaviour and focus only on compositing. So basically stop showing the objects and show only view layers, their passes and collections, besides freestyle. Also, while at this I'm also reorganizing the menu to keep View Layer and Collections on top. Developer notes: * Unlike the per-object filtering, for collections we need to filter at tree creation time, to prevent duplication of objects in the outliner. Acknowledgements: Thanks Pablo Vazquez for helping testing, thinking some design questions together and pushing this to its final polished state as you see here. Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a final review pass after I addressed his concerns. So blame is on me for any issue I may be introducing here. Sergey was the author of the "preserve scrolling position" idea. I'm happy with how it is working, thank you. Reviewers: sergey, Severin, venomgfx Subscribers: lichtwerk, duarteframos Differential Revision: https://developer.blender.org/D2992
2018-01-19 11:39:54 -02:00
outliner_build_tree(mainvar, scene, view_layer, soops, ar); // always
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* get extents of data */
outliner_height(soops, &soops->tree, &sizey);
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
if (soops->outlinevis == SO_DATABLOCKS) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* RNA has two columns:
style cleanup: outliner
2012-05-07 17:56:30 +00:00
* - column 1 is (max_width + OL_RNA_COL_SPACEX) or
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
* (OL_RNA_COL_X), whichever is wider...
* - column 2 is fixed at OL_RNA_COL_SIZEX
*
style cleanup
2013-02-13 05:10:38 +00:00
* (*) XXX max width for now is a fixed factor of (UI_UNIT_X * (max_indention + 100))
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
*/
/* get actual width of column 1 */
outliner_rna_width(soops, &soops->tree, &sizex_rna, 0);
use min/max inline functions where MIN2/MAX2 were doing type conversion.
2012-10-27 11:18:54 +00:00
sizex_rna = max_ii(OL_RNA_COLX, sizex_rna + OL_RNA_COL_SPACEX);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* get width of data (for setting 'tot' rect, this is column 1 + column 2 + a bit extra) */
Fix [#37077] User prefs > Input and Outliner Keymaps mismatch in representation. Remove KeyMap mode from outliner, was an old half-finished features redondant with user preferences settings... Also moved key map item's "event type to map type" and map type defines at WM level, this is too much generic to be at RNA level. Also added a check in versionning code to convert all outdated outliner modes to a valid one (seems old 'verse' ones were not handled as well). Thanks to Brecht for reviews and advices!
2013-10-15 13:55:06 +00:00
sizex = sizex_rna + OL_RNA_COL_SIZEX + 50;
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
has_restrict_icons = false;
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
else {
/* width must take into account restriction columns (if visible) so that entries will still be visible */
//outliner_width(soops, &soops->tree, &sizex);
Fix more UI i18n issues (reported by Leon Cheung and Lockal). We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
2013-03-11 09:06:49 +00:00
// XXX should use outliner_width instead when te->xend will be set correctly...
outliner_rna_width(soops, &soops->tree, &sizex, 0);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* constant offset for restriction columns */
// XXX this isn't that great yet...
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
if ((soops->flag & SO_HIDE_RESTRICTCOLS) == 0) {
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
sizex += OL_TOGW * 3;
Group collection viewport/render options and remove collection visibility Users can change the group collection visibility in the outliner when looking at groups. Regular collections on the other hand don't have any special visibility control, if you need a collection to be invisible during render, either don't link it into the view layer used for F12, or disable it. This includes: * Updated unittests - update your lib/tests/layers folder. * Subversion bump - branches be aware of that. Note: Although we are using eval_ctx to determine the visibility of a group collection when rendering, the depsgraph is still using the same depsgraph for the viewport and the render engine, so at the moment the render visibility is ignored. Following next is a workaround for this separately to tag the groups before and after rendering to tackle that.
2017-12-14 11:46:49 -02:00
}
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
has_restrict_icons = !(soops->flag & SO_HIDE_RESTRICTCOLS);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
}
/* adds vertical offset */
sizey += OL_Y_OFFSET;
/* update size of tot-rect (extents of data/viewable area) */
UI_view2d_totRect_set(v2d, sizex, sizey);
/* force display to pixel coords */
style cleanup: outliner
2012-05-07 17:56:30 +00:00
v2d->flag |= (V2D_PIXELOFS_X | V2D_PIXELOFS_Y);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* set matrix for 2d-view controls */
UI_view2d_view_ortho(v2d);
code cleanup: typo and warning when openmp's disabled.
2013-11-05 21:59:30 +00:00
/* draw outliner stuff (background, hierarchy lines and names) */
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
outliner_back(ar);
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
block = UI_block_begin(C, ar, __func__, UI_EMBOSS);
Cleanup: Rename ViewLayer *sl > ViewLayer *view_layer
2017-11-23 13:51:49 -02:00
outliner_draw_tree((bContext *)C, block, scene, view_layer, ar, soops, has_restrict_icons, &te_edit);
Outliner: Remove User Preferences This was introduced to the outliner when we had no User Preference window back in 2.5x. Right now it makes no sense to keep this around. But how about addon user preferences: * They belong in the user preference window under the addon. How about the user preferences themselves: * You find them in the user preference window. And templates? * Why are they here in the first place? After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found it reasonable to get rid of this. If it turns out that we were wrong we revert this. As for leaving this exposed as a debug option (as suggested on IRC) I would say no, please. This end up polluting the code and never cleaned up in the end. (this was specific talking about templates). Technical note: I left the functions in outliner still hanging around. While I used UNUSED_FUNCTION for one of them, for the other one I had to use: `#if 0` because the function was calling itself, which would fail to build if I used UNUSED_FUNCTION.
2018-01-19 15:44:26 -02:00
if ((soops->outlinevis == SO_ID_ORPHANS) && has_restrict_icons) {
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
/* draw user toggle columns */
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
outliner_draw_restrictcols(ar);
Outliner: Use restriction columns in "Orphaned Datablocks" view to manage usercounts When in "Orphaned Datablocks" mode, the restriction columns are used to display usercount indicators and toggles to manage whether datablocks get saved or not. * The first column shows an icon to indicate whether that datablock is going to get saved. A tick indicates the datablock will be saved, while a cross indicates the opposite. Clicking on this changes whether the datablock will get saved. * The second column shows the usercount. * The third column shows whether the datablock has a fake user. Notes: * The second and third columns are pretty much redundant (functionally speaking). While it is possible to also toggle fake users by clicking in the third column, its role here is more as information for power users (and hopefully to allow others to connect the relationship between the saved/not saved status and fake users) * I'm not sure whether the use of the X here for the "not saved" state stands out enough to draw user's attention to items which are "in the danger zone".
2015-02-16 00:10:33 +13:00
outliner_draw_userbuts(block, ar, soops, &soops->tree);
}
Outliner: Draw highlights over entire row Previously, highlights (mouse hover, selection, search-match) didn't affect background of restriction icons, now the entire line gets highlighted.
2016-10-15 01:38:44 +02:00
else if (has_restrict_icons) {
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* draw restriction columns */
Outliner: Fix for restriction columns This is a partial revert of 1f5106de610b115b87. First and firemost, for groups I was checking the wrong flag (soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS). Second, the columns were entirely broken for things like Orphan Data. Third, I tried to have different columns for different `outlinevis`, but we have bones with only visible and select, modifiers with visible and render, render passes with enable and another value ... I would rather stay away from this mess at the moment, and stick to the more obvious bug fix. Finally, there is a bug (not addressed here) where the whole line is selected, regardless of the restriction column area. It should be fixed separately.
2018-01-03 18:32:46 -02:00
outliner_draw_restrictcols(ar);
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
outliner_draw_restrictbuts(block, scene, ar, soops, &soops->tree);
}
/* draw edit buttons if nessecery */
fix/workaround [#36709] Renaming multiple objects in the outliner halts the interface Only show one edit button at a time (editing multiple buttons at once I never saw in other ui toolkits and its unclear what you change).
2013-09-12 22:55:42 +00:00
if (te_edit) {
outliner_buttons(C, block, ar, te_edit);
}
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
UI Refactor T41640 Make the UI API more consistent and reduce confusion with some naming. mainly: - API function calls - enum values some internal static functions have been left for now
2014-11-09 21:20:40 +01:00
UI_block_end(C, block);
UI_block_draw(C, block);
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
== The great Outliner code split up == As per my proposal (http://lists.blender.org/pipermail/bf- committers/2011-July/032553.html), I've split outliner.c into several new files based on the purpose of the relevant code. * outliner_tree.c - building outliner structure * outliner_draw.c - outliner drawing (including toggle buttons and their handling) * outliner_edit.c - all operators for toggling stuff, and/or hotkey accessed operators. Also KeyingSet and Driver operators go here * outliner_tools.c - all operators and callbacks used for handling RMB click on items * outliner_select.c - stuff for selecting rows, and handling the active/selected toggling stuff In a few cases, the split hasn't been totally clear-cut due to cross- dependencies and other spaghetti. However, in a few cases, I have managed to remove the need for some of the prototypes that were needed in the past by judicious reshuffling of functions, which also makes it easier to actually find what you're looking for.
2011-07-11 10:59:53 +00:00
/* clear flag that allows quick redraws */
soops->storeflag &= ~SO_TREESTORE_REDRAW;
}
Copy Permalink