globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
Jorg: you have added an include Python.h in the AUD api.h. I'm not
sure if it's smart to have this, it makes all AUD code depend on
resolving the Python path.
Only source/blender/editors/ dir, should not give errors on different platforms
Only removing: UI_*.h, ED_*.h, WM_*.h, DNA_*.h, IMB_*.h, RNA_*.h, PIL_*.h
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
This contains two entries - one which calls the region flip operator, and one which calls the maxmize area operator.
Unfortunately, there seem to be some context issues which are causing the wrong region to get activated for use by the region flipping, meaning that nothing happens.
Also, fixed own typo in 3d-view header/menu code...
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
Keymaps are now saveable and configurable from the user preferences, note
that editing one item in a keymap means the whole keymap is now defined by
the user and will not be updated by Blender, an option for syncing might be
added later. The outliner interface is still there, but I will probably
remove it.
There's actually 3 levels now:
* Default builtin key configuration.
* Key configuration loaded from .py file, for configs like Blender 2.4x
or other 3D applications.
* Keymaps edited by the user and saved in .B.blend. These can be saved
to .py files as well to make creating distributable configurations
easier.
Also, user preferences sections were reorganized a bit, now there is:
Interface, Editing, Input, Files and System.
Implementation notes:
* wmKeyConfig was added which represents a key configuration containing
keymaps.
* wmKeymapItem was renamed to wmKeyMapItem for consistency with wmKeyMap.
* Modal maps are not wrapped yet.
* User preferences DNA file reading did not support newdataadr() yet,
added this now for reading keymaps.
* Key configuration related settings are now RNA wrapped.
* is_property_set and is_property_hidden python methods were added.
their handlers based on notifiers, which is simpler and more
reliable.
This fixes for example editmode or uv edit keymaps not working
when creating a new 3dview or image space.
- Fun for testers: Added "Redo Operator" Panel in view3d 'nkey' region.
It's going to be part of tools UI I know, but this will give good
tests of what goes on with operators. I had to add small fixes in
Transform for it already. :)
One important issue to note is that it lists every operator, also from
non-3D-window ops. Needs checked or classified somehow.
- Fix: removed bad 2.4x hack from how pulldown menus were defined. Made
widget code cleaner, and will show menus like SHIFT+A correct now.
More cleanup!
- removed old UI font completely, including from uiBeginBlock
- emboss hints for uiBlock only have three types now;
Regular, Pulldown, or "Nothing" (only icon/text)
- removed old font path from Userdef
- removed all old button theme hinting
- removed old "auto block" to merge buttons in groups
(was only in use for radiosity buttons)
And went over all warnings. One hooray for make giving clean output :)
Well, we need uniform definitions for warnings, so people at least fix
them... here's the real bad bugs I found:
- in mesh code, a call to editmesh mixed *em and *me
- in armature, ED_util.h was not included, so no warnings for wrong call
to ED_undo_push()
- The extern Py api .h was not included in the bpy_interface.c, showing
a several calls using different args.
Further just added the missing includes, and removed unused vars.
* Made it based on string lookups rather than fixed enum, to make
it extensible by python scripts.
* Context callbacks now also have to specify RNA type when returning
pointers or collections. For non-RNA wrapped data, UnknownType can
be used.
* RNA wrapped context. The WM entries are fixed, for data context
only main and scene are defined properties. Other data entries have
to be dynamically looked up.
* I've added some special code in python for the dynamic context
lookups. Tried to hide it behind RNA but didn't find a clean way to
do it yet. Still unused/untested.
* Also minor fix for warning about propertional edit property in
transform code, and fix for usage of operator poll with checking if
it was NULL.
* Cleaned up UI_interface.h a bit, and added some comments to
organize things a bit and indicate what should be used when.
* uiMenu* functions can now be used to create menus for headers
too, this is done with a uiDefMenuBut, which takes a pointer
to a uiMenuCreateFunc, that will then call uiMenu* functions.
* Renamed uiMenuBegin/End to uiPupMenuBegin/End, as these are
specific to making popup menus. Will convert the other
conformation popup menu functions to use this too so we can
remove some code.
* Extended uiMenu functions, now there is is also:
BooleanO, FloatO, BooleanR, EnumR, LevelEnumR, Separator.
* Converted image window headers to use uiMenu functions, simplifies
menu code further here. Did not remove the uiDefMenu functions as
they are used in sequencer/view3d in some places now (will fix).
* Also tried to simplify and fix bounds computation a bit better
for popup menus. It tried to find out in advance what the size
of the menu was but this is difficult with keymap strings in
there, now uiPopupBoundsBlock can figure this out afterwards and
ensure the popup is within the window bounds. Will convert some
other functions to use this too.
Font object + editing back.
Was quite some work due to a myriad of globals all over!
Works nicely 100% local now.
To enable a single textedit operator, I've added a new
keymap entry KM_TEXTEDIT, which gives all keyboard events
to the handler. Also had to add a new keymap-add function
to force a keymap handler in beginning of region handlers.
In future this can be used to prioritize handlers.
Also: split off the arrow keys (frame change) to a separate
region level handler. Can be set with default flag in
regiontype->keymapflag ED_KEYMAP_FRAMES
* API and usage is basically the same still.
* Panels were moved to region level. I first thought of keeping them at area
level, but having them at region level it's simpler to handle events and do
drawing, and also to integrate with view2d. They can still become area level
overlapping regions, if we make a floating (or docked) region that can
contain panels.
* Added back a few panels from the scene buttons for testing.
Issues still:
* The view2d handling and alignment refresh of panels is not correct yet in the
buttons window.
* I did not yet bring back the block handlers system. It was basically a system
that stored which panel was open and where the events for that panel would go.
Just a few functions, but not sure how it fits in 2.5.
* There was a case where dragging panels would not properly remove the window
level handler, but could not redo anymore even though I don't think I fixed
it.
* Some text in the panels goes past the end of the button, that is due to the
checkmark button drawing, not related to this commit.
Other UI code changes:
* Renamed interface.h to interface_intern.h for consistency.
* Fixed some issues with freeing of blocks when they changed due to context.
* uiDrawBlock now takes a context pointer (mostly for block drawextra).
Small area/space api fix: space->new() callbacks now require
Context pointer. Too many cases you want to initialize stuff...
Also: added dummy draw function for NLA channel region, was
too ugly.
Compile fix; MAXFLOAT is not defined uniformly on platforms.
Note for the coders:
ED_types.h: has editor wide defines and structs
ED_util.h: has editor wide functions
Both includes also are containing old cruft to get things
to compile (and work), for later cleanup.
Context API
This adds the context API as described here. The main practical change
now is that C is not longer directly accessible but has to be accessed
through accessor functions. This basically adds the implementation of
the API and adaption of existing code with some minor changes. The next
task of course is to actually use this design to cleanup of bad level
calls and global access, in blenkernel, blenloader.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Context
Error, Warning and Debug Info Reporting
This adds the error reporting API as described here. It should help
clean up error() calls in non-ui code, but eventually can become used
for gathering messages for a console window, and throwing exceptions
in python scripts when an error happens executing something.
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Reports
Now, preset view configurations are only to be used if they define all (scrollers not included) relevant settings for the view they are set for. This should be less confusing than in the previous situation with V2D_COMMONVIEW_TIMELINE stuff.
One implication of this though, is that all Animation Editors (for example), will have to define their own version of the relatively commonly shared info. However, given the great diversity in the range of settings each have, this should not be too much of an issue.
Also, added a 'standard' view config for main 'window' regions. At this stage, it is recommended that this view config should be used only as a placeholder template on which a set of custom settings could be based. I've put it into use for the buttons window/scripts window/info window so far.
Improved the View2D API so that initialising View2D data in init() callbacks (called on new regions and also on resizing regions) for regions is easier.
Added a few preset view configurations for use when initialising new views. Views with the V2D_IS_INITIALISED flag set will not be reinitialised in the init() callbacks. Currently, some of these configurations will set/override all settings (like V2D_COMMONVIEW_LIST and V2D_COMMONVIEW_HEADER), while other ones serve a more supplimentary role (i.e. V2D_COMMONVIEW_TIMELINE only sets the x-axis settings, relying on the region to have already set the relevant y-axis settings).
The future of such supplimentary configurations is yet to be seen, as I'm currently not sure whether they will cause the code to become too confusing, as you'd have to keep track of which settings belong/are set where. So far, only a few areas have been ported to use this. Tomorrow I'll check on a few more.
As this commit touches a lot of files, hopefully there aren't any critical bugs I've missed here.
- depricated area "headbutofs" and "headbutlen", which is now fully
replaced with view2d handling.
- needed to add header default V2D_ALIGN_NO_NEG_Y, V2D_LOCKOFS_Y seems
to not do anything atm :)
- new: running blender in debug (blender -d) will print the current
handler and operator in use (not mousemove)
I've gone through and simplified some of the redundant options while documenting the various settings (in the code and also in the Wiki Doc), to make it clearer how to use each option.
'Preset' view-types have yet to be fully implemented, but started groundwork for this. Only some commonly used view configurations will be defined using this method. For all others, they still need to define all relavent view settings themselves (as there's too much variation in terms of the various editor's use of View2D).
IPO Editor now draws with channels on the left, like all other anim editors. Now, how to make this wider...
