Regression from rB12c71508c2d7.
Now, we systematically first try keycode from `XLookupKeysym()`, and only fall back to
the one from `XLookupString()` if it failed to convert to a valid gkey.
Why this is not working in original code and works int this one remains mystery
(see comments for details).
Note that we still do not support at all non-latin keymaps for our shortcuts,
this would be nice to add someday, but that's a TODO, not a bug.
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1746
If anyone finds OS X UI drawing glitches with different graphics cards please
report them and I'll add an exception specifically for Intel, but in theory this
should work fine for all graphics cards.
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
Issue was that dispatchEvent might call removeWindowEvents/
removeTypeEvents which will delete the event before we can do so.
To address this, handled events are now put in a separate list.
Reported by psy-fi and reviewed by brecht in IRC.
The events are allocated on the heap, then pushed on a stack. Before
being processed, they are popped from the stack, and deleted after
processing is done. When the manager is destroyed (e.g. application
closing), any remaining event in the stack is detroyed.
Issue is that when the "application closing" event is processed, it is
never freed, because the manager gets destroyed before the call to
`delete` is made and the event is not on the stack anymore.
Now events are left on the stack while they are processed, and only
popped and deleted after processing is done.
As a slight bonus refactor: use void as return type for dispatch events
functions, as no caller is checking the return value, and it is not
clear what it means (suggested by the reviewer).
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1695
In practice this gives us a context that is *compatible* with GL 2.1. On
my machine it gives a GL 3.3 or 4.3 compatibility profile context,
depending on graphics card installed.
Also fixed enum for core profile (not used yet).
Also added option for GL 3.2 compatibility profile. This will be useful
during Blender 2.8 development, until we are able to use the core
profile. On my machine this gives exactly a GL 3.2 compatibility profile
context, not 3.3 or 4.
Unfortunately there's no easy way to show a messagebox here, so just
print a warning on fstderr and exit. If we don't call exit() here we get
crashes on other blender systems (python, opensubdiv) and it can get
tricky to track the initialization state here, so just using exit()
should do the trick for now.
Load driver dynamically at runtime instead of weak-linking the
3Dconnexion framework. Driver no longer needed at build time!
Works with really old drivers (as in PowerMac old), more recent
versions, and the latest which allows us to process events on a
separate thread.
It turns out libGL from Intel crashes when calling glxewInit (where mesa, nvidia work fine),
unfortunately the only option without making larger changes to glew,
is to inline the parts of glew we're using - before the glx context is created.
The issue was caused by the following construction:
def = env['SOMETHING']
defs.append('SOMETHING_MORE')
Since first assignment was actually referencing environment option it was totally
polluted hawing weird and wonderful side effects on all other areas of Blender.
extensions, once to get final context extensions.
Not so nice because we get a warning on startup from GLEW, but at least
it GL extensions should work now.
option.
This makes sense, since contexts get created at runtime, there is little
reason to require recompilation for this.
Only works on linux currently, will be doing more OSs later
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!
As discussed in rB983c71931b1886d4, we should print a warning in case of building on non-Windows and WITH_BF_IME enabled. We also terminate build in this case, so the warning isn't scrolled away. Was worked out together with @sergey.
Original patch by @random (D765) with some minor work done by @campbell
and me.
At this place, I'd like call out a number of people who were involved and
deserve a big "Thank you!":
* At the first place @randon who developed and submitted the patch
* The Blendercn community which helped a lot with testing - espacially
* @yuzukyo, @leon_cheung and @kjym3
* @campbellbarton, @mont29 and @sergey for their help and advises during
* review
* @ton who realized the importance of this early on and asked me for
* reviewing
We are still not finished, as this is only the first part of the
implementaion, but there's more to come!
SpaceMouse Wireless
SpaceMouse Pro Wireless
Device info is from user reports. I don’t yet have the new devices, so
these are untested but likely to work :D
The ones in extern/glew-es have been changed to NOTE instead of XXX
GHOST_ContextEGL.cpp: It really does seem that it is not possible to query the swap interval using EGL
GHOST_WidnowCocoa.h: The comment referring to Carbon is clearly out of date, so I removed it.
math_geom.c: The node about not using tmax again is correct, but the code is kept for a future maintainer who will need to know how to compute it if they modify that code.
paint_image_proj.c (2698): The question about integer truncation does not appear to have been resolved. It still seems to be an incorrectly implementation of rounding (I'd suggest using the round function instead of this hack).
This is rather workaround solution for now, which seems to
work and it's not that huge to maintain (one liner apart from
the comment).
Idea is to make sure PeekMessage peeks the message when window
proc receives WM_MOUSEWHEEL (some touchpad drivers seems to
swallow the messages making it so PeekMessage doesn't get
anything).
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
- Forgot to handle command line arguments
- Because of the fact we need to be able to
use stdout and stderr we need to use regular
console application for the wrapper.
- Because of using regular application for the
wrapper we need to check forparent PID in the
isStartedFromCommandPrompt().
I really hope it's not gonna to become any more
complicated.
uses old behavior again. OSX menu and CTL-CMD-F still work as lion fullscreen as well as right-upper corner fs window-icon
- We must investigate here why double promotion happens from op calls ( dispatchEvents on redraw cause duplicated calls here )
- The actual op calls cause fs to be in a wrong state, so also mousehandles fail and CTX_wm_window(C) is not valid.
- similar problem is with quit op, which does not close the app right ( totblocks )
- i would prefer to try getting direct os function call here rather
The problem is that the render window keeps keybord input focus even after it has been
lowered. Windows maintains the Z-order of windows, so the present solution is to raise
the window that has been just below the render window.
Differential revision: https://developer.blender.org/D594
Reviewed by: campbellbarton
On earlier versions there is no proper multi-monitor support, so we leave the
choice still. But for 10.9 this just interacts better with other elements like
spaces and the dock.
With edits by Campbell, thanks!
Looks like in some cases (driver dependent?), `XDeviceMotionEvent` get generated with only part of expected data
(e.g. only x coordinate, only pressure, etc.), data which did not change since last event being NULL.
We know which data to actually handle with `XDeviceMotionEvent.first_axis` and `XDeviceMotionEvent.axes_count` values.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D208
The console window is hidden by default, but we need to avoid this when
starting from the command prompt, because it would hide the window you just
typed the command in.
Previously it would check if Blender was started from "explorer.exe" to
determine that, but that wasn't working for application launchers like
Appetizer or Colibri. Instead we now check if the process ID is the same as
the process ID of the console window, which appears to work reliably.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D122
This means that if you have WITH_BF_QUICKTIME or WITH_CODEC_QUICKTIME enabled,
it will always use QTKit.
The old backend was only used on 32 bit OS X builds, now 32 and 64 bit builds will
give consistent input/output. On Windows or Linux quicktime isn't being used.
and restore of window setups with multiple monitors, but they are also causing
regressions, in particular issues with Blender overlapping the taskbar and the
user preferences opening wrong. We decided to revert to the old behavior for
the release.
See bug #36707 for the full explanation.
Issue was caused by bug in mesa #54080 which makes
glXQueryDrawable fail with GLXBadDrawable for any
request with direct context.
Worked around by temporary overriding X error handling
when getting old interval value and disablingintervals
extension if this query fails.
Also added check for glXSwapIntervalEXT which is
apparently NULL here with GLX_EXT_swap_control=1.
There is some sort of problem with the SSE2 code path, but I couldn't find
the cause, maybe a compiler bug due to the large amount of inlining? For
now I've disabled SSE2 optimizatons in 32 bit GCC builds.
Reported by holy enigma
The previous commit in this area removed bounding box checks, because
they were done against primary monitor. Now do bound checks against
the entire desktop, or rather, the virtual screen. This is the bounding
rectangle of all the monitors.
This should ensure windows are always created within the confines of this
area.
On Windows the system window will be sized an positioned such that Blender screen area lower left
corner is at the requested location, and with dimension as requested.
Thanks to Alexander N. for reporting and Brecht van Lommel for input.
This should be (and is) done by the caller instead (windowmanager)
to ensure new windows fit properly on the desktop. Saving
stretched layouts and layouts with window over display
boundaries now becomes possible on Windows too.
The reason of this is because PATH_MAX is not guaranteed
to be defined on all platforms and Hurd doesn't define it.
So either we need to support arbitrary long file path or
we need to define own maximum path length.
The rule here would be:
- If it's not big trouble to support arbitrary long paths
(i.e. in ghost by using std::string instead of char*)
then arbitrary long path shall be implemented.
- For other cases to use PATH_MAX please include BLI_fileops.h
which takes care of making sure PATH_MAX is defined.
Additional change: get rid of own changes made yesterday
which were supposed to make storage.c work fine in cases
PATH_MAX is not define, but on the second though it lead
to unneeded complication of the code.
Thanks Campbell for review!
- Removed grid-snapping for area coordinates on scaling windows.
That caused the areas to shrink or expand, and eventually corrupt screen layouts.
- Added simple but efficient life resize for OSX. I need to know why this is so much
code for Windows... I suggest Windows to just copy same method; dispatch the queue,
and just let the event system draw.
