| Age | Commit message (Collapse) | Author |
|---|
|
Reported by Andy Braham.
Handle VK_LWIN and VK_RWIN (The infamous Windows keys). Note, these are not separate, so handled as one command key.
|
|
|
|
When the user double-clicks on a document file in the Finder, OSX doesn't simply give the filename as a command-line argument when calling Blender, as it is done in other OSes.
Instead, it launches the app if needed, and then sends an "openFile" event.
The user can also open a document file by dropping its icon on the app dock icon. But as this is not real Drag'n'drop, I've renamed the Ghost event to a less confusing "GHOST_kEventOpenMainFile" name.
DND Ghost wiki page updated : http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DragnDrop
|
|
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.
|
|
- 2 fingers scroll (MOUSEPAN / GHOST_kTrackpadEventScroll event) pans/scrolls the view
- 2 fingers pinch (MOUSEZOOM / GHOST_kTrackpadEventMagnify event) zooms the view
And in 3D view:
- alt + 2 fingers scroll rotates the view
- 2 fingers rotation (MOUSEROTATE / GHOST_kTrackpadEventRotate) orbits the view.
The implementation uses a new GHOST event type: GHOST_kEventTrackpad, that is then dispatched as Blender MOUSEPAN, MOUSEZOOM
or MOUSEROTATE events.
This is currently fully implemented for OSX (GHOST Cocoa fires the new events), with auto-detection of the source peripheral, so that a regular mouse still sends MOUSEWHEEL events.
|
|
The dragging sequence is performed in four phases:
- Start sequence (GHOST_kEventDraggingEntered) that tells a drag'n'drop operation has started. Already gives the object data type, and the entering mouse location
- Update mouse position (GHOST_kEventDraggingUpdated) sent upon each mouse move until the drag'n'drop operation stops, to give the updated mouse position.
Useful to highlight a potential destination, and update the status (through GHOST_setAcceptDragOperation) telling if the object can be dropped at the current cursor position.
- Abort drag'n'drop sequence (GHOST_kEventDraggingExited) sent when the user moved the mouse outside the window.
- Send the dropped data (GHOST_kEventDraggingDropDone)
- Outside of the normal sequence, dropped data can be sent (GHOST_kEventDraggingDropOnIcon). This can happen when the user drops an object on the application icon. (Also used in OSX to pass the filename of the document the user doubled-clicked in the finder)
Note that the event handler is responsible for freeing the received data.
And the mouse position is sent directly in blender client coordinates (y=0 at bottom)
The GHOST_setAcceptDragOperation(TRUE) call must be placed before the user drops the object for it to be accepted.
Current handled data types :
- Text string
- Array of filenames (full paths)
- Bitmap image (not implemented yet)
|
|
- Use an enum for grab modes rather then boolean options.
-- GHOST_kGrabNormal: continuous grab userpref disabled
-- GHOST_kGrabWrap: wrap the mouse at the screen bounds *
-- GHOST_kGrabHide: hide the mouse while grabbing and restore the mouse where it was initially pressed *
GrabWrap is nice for transform and tools where you want some idea where the cursor is, previously I found both restoring the mouse at its original location and restoring at a clamped location was confusing with operators like transform, wrapping is not ideal but IMHO the best of a bad bunch of options.
GrabHide is for numbuts, where restoring the mouse at the initial location isnt so confusing.
|
|
- Window creation at preferred size
Implement in Ghost the use of Cocoa functions to get the maximum visible rect (size and position) for the window contents (all screen excluding dock, top menu, and window title bar)
Thus Apple specific code in window creation (wm_window.c & wm_apple.c) is no more needed => removed in case of Cocoa build
- Alert on exiting despite unsaved changes
Add to GHOST method to maintain an all platforms (not apple specific anymore) status on unsaved changes
Update GHOST_SystemCocoa to use this for asking or not user to confirm exit without saving changes
|
|
Tested in X11 where its fairly confusing.
buttons 4 and 5 are used for the wheel which is well known, but it seems 6 and 7 are used for horizontal scrolling, my mouse assigns the extra 2 buttons to events 8 & 9.
So the X11 events used for buttons called 4&5 in blender are 8&9 in X11.
The mouse buttons can be re-ordered like this once xorg starts (swaps 6,7 with 8,9)
xmodmap -e "pointer = 1 2 3 4 5 8 9 6 7"
Couldn't test Win32, Apple not supported.
If someone wants to add horizontal scrolling its quite easy.
|
|
- last commit, missed include for rna_object_api.c & bad args to find_basis_mball
- use enum for GHOST tablet type None/Stylus/Eraser, had duplicate definition for these in C. Only tested X11, may need to cast to an int for other OS's.
|
|
Added ghost display state hint 'modified file'.
Only supported in osx though (close button in bar gets dot).
|
|
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.
|
|
* 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.
|
|
blenderplayer, using -i as input parameter to pass embedder window id. create a minimal web plugin to embed blenderplayer on web pages (using gecko/mozilla as browser). Only for *nix.
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
|
|
- 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)
|
|
added by Ettore Pasquini
|
|
turntable code should work reasonabilly well now.
fly code need works but is no more insane on Os X.
transform object is not present here.
if you find the movements a bit slow, you can speed
it in the preferences up to 2x in the view & controls
panel.
button1 (left) of the device let you switch between
the 3 modes. button2 let you switch between
unconstrained and dominant mode.
the plugin must be named 3DxNdofBlender.plug
and be placed in a folder named plugins in same
folder as executable
check no scaling is done in the plugin
please check it works ok on 3 platforms
|
|
for NDOF devices
I applied the patch but cant test so please
let me know if any problem.
the plugin itself can be found either
on Ettore site http://cubelogic/blender/
or on my site http://jlp.nerim.net/dev/6dof/
on my site there is also the source of
mac plugin
|
|
work only in non camera mode in 3D view
need the external plug-in to be compiled separately
line 894 of ghostwinlay.c must be replaced with
values adapted at your system
see mailing list for features planned and how
to use
|
|
WIP in the NDOF part, dont work yet
|
|
notes :
it compiles but is non functional
lacks the platform specific changes in ghost ( i cant test windows)
lacks the code for plug-in.
the platform specific code will be added when we sync with Ettore work
the plug-in itself cannot be added here
|
|
|
|
This is 'ported' from Nicholas Bishop's sculpting GSoC tree. I'm bringing it
over now so a) it can be there for when lukep does his GHOST refactor b) it's
something that GHOST should have anyway, particularly now there's interest in
painting tools and c) it's missing support in Windows, so hopefully now some
enterprising Windows coder can add that more easily in the main bf tree.
Right now X11 and Mac OS X are supported. I added and can maintain the Mac OS X
part, but I'm not familiar with the Xinput stuff, which Nicholas wrote. Both
X11 and Mac are collecting active device and pressure, and Mac is also
collecting x and y tilt data. Up to coders how they want to use this info! :)
Although the data's coming in, I haven't actually made this do anything. I
thought it best to leave it to brecht to figure out what he wants to do with the
painting stuff, and I wonder what other interesting uses there could be for it
(proportional edit?). I'll write implementation details in a separate mail to
the committers list.
|
|
|
|
lot of casts, added prototypes, missing includes and some true errors
|
|
ghost was unaware of extra *<>* key on german keyboards on windows
|
|
message on Bf-committers for description.
|
|
Florian Eggenburger).
Full instructions are in doc/README.windows-gcc.
Main differences from Florian's patch:
- the 'lib' dir should now be the same level as the 'blender' dir (rather
than being a subdir of 'blender'). This is consistent with the other
platforms that bf-blender supports (tuhopuu will also adopt this convention
hopefully soon).
- the script 'free_windows-env.mk' is no longer needed ... see the
docs about how this is overcome (again, tuhopuu will hopefully
also follow this route soon).
- the dlltool dir has it's own Makefile that builds all of the
needed stub libraries from the dll's in cvs.
|
|
Only working (soso) on osx.
Maarten
|
|
Gilles meant) and added some extra doxygen tags I had lying around.
Removed the cocoa file since it was rubbish.
Maarten
|
|
I took out the following from the includes in the intern dir that still had
it:
-#ifdef HAVE_CONFIG_H
-#include <config.h>
-#endif
Kent
--
mein@cs.umn.edu
|
|
added the following 3 lines to everything in the intern dir:
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
Kent
--
mein@cs.umn.edu
|
|
little minor spacing issues.
|
|
|
