- operator definitions, callbacks, registry to WM and handlers for it are
now always in a file xxxx_ops.c or xxxx_operators.c, in the bottom you
will find the registry and handler code.
- fixed some confusing naming conventions "rip_area vs area_join" etc. Now
stick to convention to first name subject, then operation (like UI :).
So it's area_rip, screen_add, and so on.
- Nicely put exported calls (outside module) together in bottom: this using
names such as ED_screen_duplicate().
- Moved Operator-Property API to new C file.
- Simplified and cleaned previous border code
It was a bit too complex, too many data manipulations
Original idea was to have WM API calls to manage border, circle, lines,
lasso, etc. This now means that WM provides callbacks for custom operators,
so it's very easy to make them. Check bottom of screen_edit.c for an
example.
Currently two borders were coded; with and without cross hair.
Press Bkey in any area-region to test it (note: time window has wrong matrix!)
Some specs to note:
- gestures are in region space, and draw 'over'. That latter still needs some
work when we do real composites.
- only the active region is redrawn.
- on todo is the generic gesture engine for 'tweak' or like how currently grab
gestures in Blender work. These will be configurable per area-region, and WM
then will send the proper "Gesture Event" with properties (N, S, E, W, etc)
to which you then can assign operators. Such events will be generated with low
priority, so other handlers who swallowed mouse events have preference.
- moved from WM to Screen code (it uses active area)
- less code :) result of cleaning some calls
- added WM_window_open() to WM API for this
- now opens new window on top of area, and leaves old screen unaffected
(simple, atomic, the 'do not think for user' convention :)
- cleaned up join and split operations. Most noticable is operator callback
design, which should make a design based on user-less exec() first, then
wrap invoke() and modal() around it. The exec() should be callable with
only Context and properties.
- split now works again; and inversed as previously, if you drag from a
triangle (action zone) inside area it subdivides area as expected.
- dragging from triangle outside area, over an edge, joins areas
- split has been simplified, it had too many options... it could just work
simpler (now)
- 'action zone' now is an operator itself, a widget sending an ACTIONZONE event,
which can be handled by others (so other gestures can be added in action zone
too)
Still evaluating:
- context gets set where?
- code structure confuses... what are proper functions for operators?
- what is WM... should low level screen stuff more there?
- when do you send event, notifier?
- files grow to large, will clean
Oh yeah and docs, docs, docs. Coming! :)
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
This is based on the current trunk version, so these files should not need
merges. There's two things (clipboard and intptr_t) that are missing in 2.50
and commented out with XXX 2.48, these can be enabled again once trunk is
merged into this branch.
Further this is not all interface code, there are many parts commented out:
* interface.c: nearly all button types, missing: links, chartab, keyevent.
* interface_draw.c: almost all code, with some small exceptions.
* interface_ops.c: this replaces ui_do_but and uiDoBlocks with two operators,
making it non-blocking.
* interface_regions: this is a part of interface.c, split off, contains code to
create regions for tooltips, menus, pupmenu (that one is crashing currently),
color chooser, basically regions with buttons which is fairly independent of
core interface code.
* interface_panel.c and interface_icons.c: not ported over, so no panels and
icons yet. Panels should probably become (free floating) regions?
* text.c: (formerly language.c) for drawing text and translation. this works
but is using bad globals still and could be cleaned up.
Header Files:
* ED_datafiles.h now has declarations for datatoc_ files, so those extern
declarations can be #included instead of repeated.
* The user interface code is in UI_interface.h and other UI_* files.
Core:
* The API for creating blocks, buttons, etc is nearly the same still. Blocks
are now created per region instead of per area.
* The code was made non-blocking, which means that any changes and redraws
should be possible while editing a button. That means though that we need
some sort of persistence even though the blender model is to recreate buttons
for each redraw. So when a new block is created, some matching happens to
find out which buttons correspond to buttons in the previously created block,
and for activated buttons some data is then copied over to the new button.
* Added UI_init/UI_init_userdef/UI_exit functions that should initialize code
in this module, instead of multiple function calls in the windowmanager.
* Removed most static/globals from interface.c.
* Removed UIafterfunc_ I don't think it's needed anymore, and not sure how it
would integrate here?
* Currently only full window redraws are used, this should become per region
and maybe per button later.
Operators:
* Events are currently handled through two operators: button activate and menu
handle. Operators may not be the best way to implement this, since there are
currently some issues with events being missed, but they can become a special
handler type instead, this should not be a big change.
* The button activate operator runs as long as a button is active, and will
handle all interaction with that button until the button is not activated
anymore. This means clicking, text editing, number dragging, opening menu
blocks, etc.
* Since this operator has to be non-blocking, the ui_do_but code needed to made
non-blocking. That means variables that were previously on the stack, now
need to be stored away in a struct such that they can be accessed again when
the operator receives more events.
* Additionally the place in the ui_do_but code indicated the state, now that
needs to be set explicit in order to handle the right events in the right
state. So an activated button can be in one of these states: init, highlight,
wait_flash, wait_release, wait_key_event, num_editing, text_editing,
text_selecting, block_open, exit.
* For each button type an ui_apply_but_* function has also been separated out
from ui_do_but. This makes it possible to continuously apply the button as
text is being typed for example, and there is an option in the code to enable
this. Since the code non-blocking and can deal with the button being deleted
even, it should be safe to do this.
* When editing text, dragging numbers, etc, the actual data (but->poin) is not
being edited, since that would mean data is being edited without correct
updates happening, while some other part of blender may be accessing that
data in the meantime. So data values, strings, vectors are written to a
temporary location and only flush in the apply function.
Regions:
* Menus, color chooser, tooltips etc all create screen level regions. Such menu
blocks give a handle to the button that creates it, which will contain the
results of the menu block once a MESSAGE event is received from that menu
block.
* For this type of menu block the coordinates used to be in window space. They
are still created that way and ui_positionblock still works with window
coordinates, but after that the block and buttons are brought back to region
coordinates since these are now contained in a region.
* The flush/overdraw frontbuffer drawing code was removed, the windowmanager
should have enough information with these screen level regions to have full
control over what gets drawn when and to then do correct compositing.
Testing:
* The header in the time space currently has some buttons to test the UI code.
* Added functions to generate Timer events. There was some unfinished code to
create one timer per window, this replaces that with a way to let operators
or other handlers add/remove their own timers as needed. This is currently
delivered as an event with the timer handle, perhaps this should be a notifier
instead? Also includes some fixes in ghost for timer events that were not
delivered in time, due to passing negative timeout.
* Added a Message event, which is a generic event that can be added by any
operator. This is used in the UI code to communicate the results of opened
blocks. Again, this may be better as a notifier.
* These two events should not be blocked as they are intended for a specific
operator or handler, so there were exceptions added for this, which is one
of the reasons they might work better as notifiers, but currently these
things can't listen to notifier yet.
* Added an option to events to indicate if the customdata should be freed or
not.
* Added a free() callback for area regions, and added a free function for
area regions in blenkernel since it was already there for screens and areas.
* Added ED_screen/area/region_exit functions to clean up things like operators
and handlers when they are closed.
* Added screen level regions, these will draw over areas boundaries, with the
last created region on top. These are useful for tooltips, menus, etc, and
are not saved to file. It's using the same ARegion struct as areas to avoid
code duplication, but perhaps that should be renamed then. Note that redraws
currently go correct, because only full window redraws are used, for partial
redraws without any frontbuffer drawing, the window manager needs to get
support for compositing subwindows.
* Minor changes in the subwindow code to retrieve the matrix, and moved
setlinestyle to glutil.c.
* Reversed argument order in WM_event_add/remove_keymap_handler to be consistent
with modal_handler.
* Operators can now block events but not necessarily cancel/finish.
* Modal operators are now stored in a list in the window/area/region they were
created in. This means for example that when a transform operator is invoked
from a region but registers a handler at the window level (since mouse motion
across areas should work), it will still get removed when the region is closed
while the operator is running.
- operator that rips current area into new window
- implemented on the window level.
- sets C->area in current context if necessary
== fix ==
- small bugfix: missing return in WM_event_add_keymap_handler
==========
* Changed wmOperatorType, removing init/exit callbacks and adding cancel
callback, removed default storage in favor of properties. Defined return
values for exec/invoke/modal/cancel.
* Don't allocate operator on the stack, and removed operator copy for
handlers. Now it frees based on return values from callbacks, and just
keeps a wmOperator on the heap. Also it now registers after the operator
is fully finished, to get the correct final properties.
* Changed OP_get_* functions to return 1 if the property is found and 0
otherwise, gives more readable code in my opinion. Added OP_verify_*
functions to quickly check if the property is available and set if it's
not, that's common for exec/invoke.
* Removed WM_operatortypelist_append in favor of WM_operatortype_append
which takes a function pointer instead of a list, avoids macro's and
duplicating code.
* Fix a crash where the handler would still be used while it was freed by
the operator.
* Spacetypes now have operatortypes() and keymap() callbacks to abstract
them a bit more.
* Renamed C->curarea to C->area for consistency. Removed View3D/View2D/
SpaceIpo from bContext, seems bad to keep these.
* Set context variables like window/screen/area/region to NULL again when
leaving that context, instead of leaving the pointers there.
* Added if(G.f & G_DEBUG) for many of the prints, makes output a bit
cleaner and easier to debug.
* Fixed priority of the editors/interface module in scons, would otherwise
give link errors.
* Added start of generic view2d api.
* Added space_time with some basic drawing and a single operator to change
the frame.
After check this a little more I make some changes to the
API and now work on the following form:
WM_gesture_init(C, type);
while() {
/* handler event, etc */
/* if something change. */
if(need_update) {
/* update the gesture data and notify about it. */
WM_gesture_update(C, data);
WM_event_add_notifier (.. WM_NOTE_GESTURE_CHANGE ..);
}
}
WM_gesture_end(C, type);
Another of the change is that now the gesture data is a link list
in the window struct, so we can have multiples "gestures" (but
of different type) at the same time.
Also take care that the "gesture data" is reusable, that mean that
only alloc it 1 time and use in all the place, that is
why don't support multiple gesture of the same type, but of course
that can be change.
This is a first implementation of the "gesture manager" system,
the idea is put the WM in a automatic draw mode so we can
implement different "Gesture types" to draw different class
of data (lasso, bound box, etc).
The gesture data is passed through the data field of the notifiers,
i think that we can change this to something like:
WM_gesture_init(C, data); /* put the data in the context. */
while() {
/* send WM_NOTE_GESTURE_CHANGED to update screen */
}
/* send event and free the data in the context. */
WM_gesture_end(C);
Also i add a new operator and event to test the gesture manager.
The new operator is the "border select" function, just press BKEY
in the window and LMB or ESCKEY to exit.
In the case of LMB you can see a print in the console about the
BORDERSELECT event.
All this still need a lot of work, comment are welcome.
add split area to screen manager
- RMB+ALT down on area edge activates
- mouse move interactively to area that is to be removed
- LMB to confirm, ESC to cancel
TODO:
- notifications for interactive drawing to mark area to remove
Some fixes
- uninitialized var warning.
- exit function of operators need to run before modal handler is removed if operator is used there.
- replaced MEM_mallocN with MEM_callocN to get rid of uninitialized mem for wmOperator.
- respect return value of wm_handler_operator_call() and break out of operator handling.
Now you can set/get: float, arrays (int and float) and string.
The only special function is OP_get_string, it is special
because return a pointer to the IDProperty data, so you can't
change/resize/free the string.
It's possible "fix" this with:
1) Return a "const char"
2) Return a duplicate string
All this new function are not in use yet, but i make a simple test
with the "move areas" operator (add a property of every type and then
print the result in the other size) and work fine, more test are welcome.
Other thing to check is the new OP_free_property function, because this
properties are only local to the operator, i choice free all this in the
"exit callback" of every operator (only move areas have property now),
so comment about this are welcome too :)
Also add some notes to the WM_api.h file.
This is a simple API around IDProperty to store properties
in the Operator, it is really simple and this first commit
just add support for IDP_INT data type.
Take care that this "properties" are not save yet and you get
some "Error totblock" more with this.
I add some notes to the WM_api.h file, please check this,
comment and ideas are welcome.
- on mouse-over edge, you can drag area borders around.
- note it's a handerized system now, so it updates UI while you
move mouse.
Feedback needed:
- read bottom part of the screen_edit.c file. It's the proposed
method for adding tools and handlers. I think it's close, but
might need some tweaks.
- removed editors/area and put this all in screen
- added first python calls (note, a new c file for scriptlinks)
- added view3d editor callbacks (no drawing yet)
- added files in editors/interface
(Cmake and Scons has to be fixed, help welcome!)
- now areas/headers are being converted on file read
- note: previously saved 2.50 files will crash!!! (.B.blend)
- area regions are being drawn, first handler for cursor added (on edge)
- window duplicate and scale works correct for screen subdiv
Todos for me:
- need to fix things in syntax (function names) a bit still
- more operators for screen
- define how Context will work... still unresolved when it gets set
- docs!
Reviews of code structure is welcome!
There are also more todos now for others, but it can wait a couple of days
- first work on getting area/screen handling back
- added structure for where to put stuff, is still under
review, wait a bit for docs?
Campbell is working on removing every bad level include from
sources, so we can safely rebuild the src/ directory.
* made win32 ghost getClientBounds so that it returns area compatible with osx getClientBounds
- if a window is non-fullscreen, substract decoration, since that'll be added by GHOST_WindowWin32()
* use SetWindowLongPtr/GetWindowLongPtr (instead of SetWindowLong) as it is compatible with 64bit windows.
Result: windows open default with decoration (or as your default WM
defines).
Todo: platform maintainers re-implement a cogent way for giving
commandline options for defaults, and test how this can be stored even
- Added GHOST_kEventWindowMove event, for sending event that the
window has moved
- Fixed GHOST_GetClientBounds() for OSX (get window rect)
Todos:
- add same event for X11 and Windows
- solve why ghost doesn't call client event-proc while scaling window
(at least, not in osx)
