when loading them. Custom cursor shown during load was not freed correctly
when closing the old window, which resulted in unpredictable crashes later on.
Actual problem was caused by insufficient buffer size
in ui_text_leftclip()
Also fixed possible invalid memory write in GHOST_SystemWin32::getClipboard
which was caused by accessing clipboard buffer after closing
clipboard. This mustn't happen.
Also fixed possible crush when buffer was failed to be locked.
some WMs not only send 'crossing' events when really moving from one
window to another, but also when mousewheeling.
distinguishing those events 'mode' property fixed this.
brecht++ for figuring out the details.
(patch co-reviewed by Nathan Letwory)
Overview: GHOST using rawinput for keyboard input. GHOST window receives WM_INPUT only when it is the active window. Child window cannot be active, so when embedding blenderplayer, WM_INPUT is consumed by top level parent window (for Burster it is the web browser window). Patch register raw input device as 'inputsink' - it makes GHOST window receives all keyboard messages. Window procedure check if GHOST window is active or focused.
::TranslateMessage(&msg) generates WM_CHAR etc. messages from WM_KEYDOWN, WM_KEYUP etc. Because of using RawInput only WM_INPUT messages are processed, so we doesn't need WM_CHAR, WM_KEYDOWN etc. [this is why ::TranslateMessage is no longer getting called].
Note: It's responsibility of the parent window (aka the wrapper) to send WM_SETFOCUS to child window (embedded blenderplayer).
However some parent windows (e.g. webbrowsers) will not send WM_SETFOCUS to the child window when someone clicks on it.
In those cases the blenderplayer needs to be patched to call setFocus(&msg); in the event of WM_LBUTTONDOWN (see GHOST_SystemWin32.cpp)
The patch can also be found in http://codereview.appspot.com/4431072/
##############
This patch fix anti-aliasing (multisampling) implementation for win32 platform. It also gives opportunity to embed blenderplayer inside parent window.
Usage:
blenderplayer.exe -i 123456 -m 16 file.blend
where:
123456 - parent window handler (integer, default: 0)
16 - multisample level (integer, default: 0, max: 16. Put there maximum level you want. If not supported, player will automatically try 15,14,13,...,3,2,1)
##############
This patch was originally created as part of the Burster (aka webplugin) project but benefit any one embedding the bge in a custom OpenGL context. By the way, to embed the BGE in a .Net application is really straightforward now =)
The Multisampling work for blenderplayer as a whole.
Missing functionalities:
- to expose the multisampling to the ui (so far it only works in console)
- window focus and keyboard messages for embedded blenderplayer (supported in their previous patch for 2.49, yet to be ported over)
- handle resizing (to be investigated, indeed the changes in getState() in GHOST_WindowWin32.cpp are going to get in the way of that if I'm not mistaken. To be addressed together.
Doxygen documentation to be added whenever I sort out how to do so. Sorry Nathan too many stuff to deal with at the same time. The sooner this patch gets in, the sooner the missing functionalities can be patched on top of that.
Reported by Thomas Engel
Fix [#26938] Blender Zoom not working after startup (Windows)
Reported by Ilija Boshkov
by applying patch [#26881] Fix for console disappearing in debug mode [Windows]
Submitted by Alexander Kuznetsov (AlexK)
The patch moves console toggling code into GHOST and improves on the toggling behaviour.
The patch changes handling of WM_SYSCOMMAND so that alt-key toggling isn't a problem anymore.
- ghost C api, BLI_get_folder_version() could assign garbage values.
- pointcache ptcache_find_frames_around() had a superfluous NULL check which would have crashed anyway if actually NULL.
This crash was discovered by Dalai and this happened because of
unset current context (as result of call wglMakeCurrent(NULL, NULL)).
In this case glGetString(GL_VENDOR) returns NULL. Rather than add check
for vendor != NULL before string comparison, I've changed a bit logic of
context creation:
- Create context and set it as current
- If it's crappy Intel card -- delete this context and
share the only one context between all Windows
- Otherwise, use initial logic (with sharing lists and so on)
This could also fix crash when opening userprefs from a menu with Intel card.
Intel video cards don't work fine with multiple contexts and
have to share the same context for all windows. This could work
incorrect with multiple video cards configuration, so suppose
there'll be no such situation (Intel cards are mostly in portable
devices like notebooks and laptops, where there's actually no
dual video cards). Anyway, it should work much better now.
Non-Intel cards behavior was kept unchanged.
Thanks to Ton for debug session :)
reported by Georg K
with patch [#26469] Windows mouse fix
by Alexander Kuznetsov
The amount of mouse grabs wasn't properly balanced with ungrabs, thus preventing from using proper mouse input outside client area.
Submitted by Alexander Kuznetsov
Fixes [#25279] Shift-Numpad Combinations fail to align view to selected
and addresses [#26328] Blender uses global keyboard message hook which hurts system responsiveness on Windows
A whole new way of handling keyboard input improves greatly both code readability and event handling. Thanks for the great patch, Alexander!
available on many keyboards these days, so that they can be used for
animation playback (giving more options over alt-a and alt-a ad-
infinitum).
Currently, this is Windows only as I don't have a Linux/Mac system to
test on (it should compile with both mingw and msvc, at least using
scons). Maintainers for those systems can probably easily add this in
once they find out the relevant mappings for those systems.
Some reorg of modules/pages, start makesdna and makesrna.
In many places license block needs to be changed to not start with /**, because otherwise documentation will go weird.
reported by Micael Dias (and many others, see duplicates list)
On closing the first ("main") Blender window the very first OpenGL context
got deleted too. This context needs to be retained, since we share quite a
bit of OpenGL data through it to the newly created contexts (new windows).
Thanks to Ton Roosendaal for thinking out loud while trying to figure out
what the actual cause was.
The console was getting flooded with output like
g
i
i
...
all as a result of what looks like a debugging print. Whoever put this
in, you can get back your debugging prints by enabling BF_GHOST_DEBUG
in your local config :)
Submitted by Alexander Kuznetsov.
This adds the progress bar to the taskbar item of Blender for Windows 7.
Small change in version retrieval, otherwise as is.
Some window manager can set default value of this to be the
screen size, so running blender with -p or --window-geometry
don't work with value bigger than that.
This commit try to "avoid" the bug #25709, but at the end
depend on the window manager, so maybe work or maybe not.
Slightly modified to better fit in architecture (moved to related GHOST SystemPaths)
Thanks to Harley Acheson for the research and for providing the original patch.
Note: I added empty function for X11(Linux) and Mac (Carbon and Cocoa) to be implemented still.
Reported by Nils Austa
There was double handling of modifier keys. With my autumn work on the modifier keys I had moved state checks for
modifier keys into convertKey(), but left the call to handleModifierKeys. That caused problems with proper
modifier key handling in the entire key handling code of GHOST.
Problem is is with operator redo which click-extrude exposed.
Check if redo operator can run, otherwise lock the UI and add a label that the operator doesn't support redo.
This is clunky but IMHO better then failing silently and leaving the user confused.
- Merged redo functions into ED_undo_operator_repeat(), code was duplicated in a few places.
- added WM_operator_repeat_check to check if WM_operator_repeat() can run, avoids an undo call when redo work.
Unrelated changes
- GHOST_SystemWin32.cpp set to utf8 encoding.
- cmake_consistency_check.py now checks source files are utf8.
reported by Eclectiel L
When working with very heavy scenes Blender can seem to 'hang' (not responding). Key events that happen
during this period may get lost, especially for modifier keys.
Adding extra handling to account for these situations.
Reported by Lluc Romaní Brasó
Some of my earlier changes to the modifier handling code accidently sent out new events for modifier keys when they where held down (repeat).
Also lay foundation for shift+numpad handling.
It was impossible for keyboard layouts that use AltGr to create certain characters to insert
them in Text and Console.
The keyboard driver in Windows sends left control events when AltGr is pressed. This meant that
Blender thought control was being held, which is a PASS_THROUGH condition for the insert operator
in both editors.
Add testing of keyboard layout for AltGr, both on initialization and WM_INPUTLANGCHANGE.
To remedy AltGr problem, we send now a left control key up event to Blender before further processing
the AltGr key.
Reported by Andy Braham
Handle XK_Super_L and XK_Super_R as the GHOST_kKeyCommand. Since Command key is
not discerned (yet) in left/right variants, read both and set accordingly.
This now completes fixes for [#21395]
- ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings.
- the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
The remains of a RawInput mouse attempt are included, but disabled. RawInput will still be used for multi-axis devices.
Eliminated the need for several #defines by requiring WinXP or newer.
Update after discussions on IRC:
* operating system specific path retrieval is moved back to GHOST, nothing blender specific here though
* cleaned up path functions a bit to remove #ifdefs
* removed Cocoa from blenlib again
TODO:
* Matt, Damien, please check and correct the functions for Cocoa and Carbon, could only put back existing code but needs adjustment
* finish GHOST_getBinaryDir - this should replace the BLI_where_am_i eventually as well as BLI_getInstallationPath on Windows and get_install_dir for the blenderplayer runtime
* It would probably be nice to define GHOST_getTempDir as well and move those out
* more cleanups...
NOTE:
Things are likely broken for macs
Displays a global progress indicator in the application icon reflecting the total progress of all running jobs.
Currently fully implemented on OSX (Cocoa).
On other OSes that do not allow to redraw the app icon, this can be implemented as a [x%] display in the app title, so to appear in the taskbar.
Thanks to Matt for the windowmanager wrapper.
Cocoa charactersIgnoringModifiers API still takes the Shift key into account. Fix is to use Apple new 10.5 Carbon(!) API that is 64bit compatible to take into account the international keyboard layout when retrieving the physical key pressed/released.
Needed to use an even older API for 10.4 builds.
* move own thread handling for thumbnails to WM_jobs
* cleanup of thumbnail creation code
* added function to kill the job, which actually allows thread to terminate gracefully
vc9 projectfiles:
* fixed some missing includes for release target!
10.6 new function to get modifiers flags status asynchronously returns erroneous value when application gets focus after a virtual desktop switch (Spaces).
Use legacy method to retrieve the modifiers flags status sent with the last event. Works as at least the "focus gained" event is sent before this query. Bonus: should work also on pre-10.6!
Previous code was assuming an event can only be sent from the active window.
On OSX, Right, Middle mouse buttons, mouse wheel and trackpad events are sent to inactive windows too.
For example, this allows to zoom, pan the view without changing the window order.
The '+' in the cursor during the DND operation is displayed only if drop is accepted.
(through a previous call to GHOST_setAcceptDragOperation(window, TRUE); )
With continuous grab on, in 2+ window setup, when RMB-dragging an object in a 3D view of a not active (not frontmost) window, mouse cursor was stuck, with no escape.
Cursor grab must be done by the window that is key (able to receive mouse move events).
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
Cocoa can still send events (tagged with the correct NSWindow handle) after having sent the window deactivate event.
This caused these events being discarded as there was no active window for GHOST_WindowManager.
Fix is to use this NSWindow handle to retrieve the target window and correctly push the event.
E.g. of effects of this bug: OSKey modifier stuck after having invoked Spotlight through its shortcut (Cmd + Space). This gave the impression the Blender window has not got focus back for the keyboard.
Ton, can you confirm if this fixes the "Cocoa window loses focus permanently on using Spotlight" issue you found ?
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.
- transform default scale was too hight, calls to random were inconsistant. (fault of own modif's)
- cmake openal include was added twice on recent commit.
- fix race condition between applicationBecomeActive, and WindowBecomeKey events that discarded the modifiers keys status change event message
- workaround for a 10.6 bug that made the Cmd (oskey) modifier erroneously on.
Note: AA is still disabled due to AA creating problems for selection tools. If you must, set AA to 2 or 4 in wm_window.c where the GHOST window is created (line 317).
- 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.
Added GHOST_TUns16 numOfAASamples parameter to GHOST_CreateWindow to specify the number of AA samples (null if no AA wanted)
Implemented it in the cascade of GHOST classes.
Full implementation currently done for OSX/Cocoa, stubs for other OSes.
Moguri : it's ready for your win32 implementation !
Note that fallback to a non AA window (if gfx card doesn't support AA) is done inside GHOST OS specific layer, so that blender windowmanager still gets its window created properly.
On X11, the opengl context was destroyed when closing a window. This lead to
the text and icon textures being lost (among other things), now the opengl
context is kept like on Win/Mac.
* added some new variables (mostly the same as with scons):
- USE_COCOA: use Cocoa for ghost (defaults to true)
- MACOSX_ARCHITECTURE: can be ppc, ppc64, i386, x86_64. By default this is the host architecture
(ppc for PowerPC Macs, i386 for Intel Macs). In theory this allows to cross compile blender for
a different architecture, though cross compilation only works on Intel Macs, because makesdna
and makesrna are built for the target architecture.
For a 64 bit build, set MACOSX_ARCHITECTURE to x86_64 (Intel) or ppc64 (PowerPC).
- MACOSX_MIN_VERS: minimum OS X version to run blender on (10.4 for 32 bit builds, 10.5 for 64 bit builds)
- MACOSX_DEPLOYMENT_TARGET: needed by the linker to create an Application targeted for a specific
OS version (defaults to 10.4 for 32 bit builds, 10.5 for 64 bit builds)
- MACOSX_SDK: path to a specific SDK. currently not used
- USE_QTKIT: use QTKit instead of QuickTime (defaults to true for 64 bit builds, as using QTKit
is mandatory in that case))
* use the same compiler flags as scons
* default compiler now is gcc-4.0 when building for 10.4 and gcc-4.2 when building for 10.5
* extract $(LCGDIR)/release/python_$(MACOSX_ARCHITECTURE).zip to Application bundle. This might
break building on 10.4, to fix that, rename $(LCGDIR)/release/python.zip
When compiling blender, only MACOSX_ARCHITECTURE might be of interest, as it allows doing 64 bit
builds (or 32 bit PowerPC builds on Intel). All other variables are then set to reasonable defaults.
For current users of the Makefile system, this commit shouldn't change much.
This nice patch by Matt D. (matd in #blendercoders) adds three nice features that can be seen already in the other supported OSes:
* minimum window size: to prevent some bugs with the window manager of Blender, system windows cannot be resized smaller than the minimum size.
* Continuous Grab is finally in Windows! Default settings since alpha 0 already have the feature enabled by default, so grab a new build and enjoy :)
* GHOST support for drag and drop added. This prepares Blender for drag and drop from OS -> Blender. Currently not very useful, since wm needs to be readied for that. But it does work (do BF_GHOST_DEBUG=1 build and drag a file onto a Blender window).
Thanks Matt D.!
Note: this works fine when running under 10.6, even if compiled with an older sdk
Under 10.4/10.5, workaround remains to assume no modifier key is pressed when the user restores the focus to the application
The carbon GetModifierFlag function (to get the current modifier keys status) is reimplemented in cocoa only from 10.6.
So we need to use a workaround to get the correct modifiers when blender application gets focus back. Current one is to assume no modifiers.
This at least fixes the issue when blender has been hidden using Cmd+H. The Cmd modifier was still seen as ON until the user pressed again on it.
