The issue was caused by using NotificationCenter which is only available
since 10.9 so trying to build blender on OSX with 10.7 SDK would fail.
Now it should be possible to build blender with SDK 10.7 and at the same
time official builds should still be doing proper weak-linking to a
notification center.
AFAIK a few IMEs were affected by this so I guess we can now add a
few more IMEs to the "officially supported" list.
Patch by @randon (thanks again!), minor edits by me.
Removed window arg from key conversion functions.
Removed processModifierKeys declaration since that function was
apparently never implemented.
Using Win32-specific classes instead of their generic superclass -- this
helps in a few cases like WinTab.
* m_hDC was always included after m_hWnd in all the constructors and other functions,
but the order was reversed in the struct, meaning that they would not get initialised
correctly
* Got rid of the gotos for the error handling case in initializeDrawingContext()
This was causing "jump to label ... crosses initialisation" errors for the calls
to get GL version string info (i.e. const char *vendor = ...; etc.) I wasn't sure
if those glGetString calls needed the rest of the context to be defined first, so
I decided to leave them where they are now, and got rid of the gotos (which were
making this particular piece of code a bit confusing) instead.
TODO:
There are still a bunch of warnings about around 660, which I haven't managed to solve
(but at least they won't prevent Blender from compiling)
narrowing conversion of '(stereoVisual ? 1063 : 1061)' from 'int' to
'DWORD {aka long unsigned int}' inside { } is ill-formed in C++11 [-Wnarrowing]
OpenGL is detected:
Hoping to decrease the frequency of by far one of the most frequent bug
reports by windows users.
There is some reorganization of the GHOST API to allow easy addition of
further OpenGL options in the future. The change is not propagated too
deep to keep the size of the patch managable. We might reorganize things
here later.
For OpenGL we do two checks here:
One is a combination of GDI generic renderer or vendor microsoft
corporation and OpenGL version 1.1. This means the system does not
use GPU acceleration at all. We warn user to install a graphics
driver and of cases where this might happen (remote connection, using
blender through virtual machine)
The other one just checks if OpenGL version is less than 1.4 (we can
easily change that in the future of course) and warns that it is
deprecated.
Both cases will still let blender startup correctly but users should now
have a clear idea of the system being unsupported.
A user preference flag is provided to turn the warning off.
Now stop posting those bug reports without installing a driver first -
please?
patch number D706 with changes:
- WITH_GPU_DEBUG just creates a debug context (and enables the debug messaging
system functions) but leaves the checks we had intact. Old patch
added the debug functionality only if we had the flag on to save some
performance.
Rationale here is that we might not want to recompile blender just to get
the extra information, and having users start blender with a -d flag to
get the extra information is also useful for bug reports. Those checks already
existed and most expensive ones are hidden behind a debug mode check
so performance should not be that bad.
- Did some cleanup of existing functionality:
When things go wrong blender side, just print the error,
don't check for GL errors first.
- Did not port changes needed for GLES to regular glew.h
- Got rid of duplicate or very similar new functionality.
Generally, code is more moving things around/cleanup and should work exactly
as before apart from the debug context, so it's safe to add even now.
It also provides a nice substitute function for glu error descriptions
Yes, for me tablets (both wacom and no-name) were again broken - curse X11!
So now, we want ButtonPress, Button1Motion does not work anymore...
Anyway, this patch makes things much cleaner, storing each event type
in its own variable!
Patch by cedricp (Cédric PAILLE) from T43367, thanks a bunch!
Was filtering for Logitech's USB vendor ID. 3Dconnexion now uses their
own vendor ID for new products. Mac & Windows don't look for specific
vendors so they should be fine.
Also added a note to eventually make USE_FINISH_GLITCH_WORKAROUND
available on all platforms.
Reined back over-use of virtual functions in GHOST, especially in
"leaves" of the inheritance hierarchy. This eliminates vtables for many
classes and (in some places) turns virtual function dispatch into direct
function calls.
I'll be around to fix things if other coders think this change is too
much.
Still lots of virtual in GHOST_TaskbarWin32 since it just loves virtual.
Looks like with some versions of Xlib (at least the 1.6.2 currently used on Debian testing)
and/or evdev generic driver (2.9.0 currently on Debian testing), you have to also 'select'
DeviceButton1Motion with the extended tablet's motion event, otherwise you won't get any
tablet motion event once pen is pressed, leading to no pressure (each stroke keeping its
init pressure until the end). Crap!
