Age | Commit message (Collapse) | Author |
|
Many keyboard layouts (italian, spanish, german...) have direct access to '+' key on main
keyboard area (not the numpad one), ans x11 has own define for this key, so use it instead
of generating an unkown key event.
Note that we most likely have much more missing 'specific' keycodes for non-US keyboard layout,
but think since we already had a 'minus' keyevent, supporting 'plus' one is totally consistent.
And we had a spare space in our defined values just for it even!
This keyevent is only supported/generated by x11 and cocoa Ghost backends for now,
neither SDL nor win32 seem to have matching key events...
|
|
|
|
|
|
This allows us to get rid of annoying and misleading error printed to the console
about being unable to connect to something.
|
|
|
|
|
|
Should b totally harmless since the define was overriten anyway.
|
|
|
|
|
|
Hopefully this is the last fix, using the method explained here:
https://forums.developer.apple.com/thread/31536
|
|
mode on off anymore.
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.
|
|
on OS X.
|
|
non-latin.
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
|
|
|
|
X11 property access was using wrong sized types that only worked for little endian systems.
|
|
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
|
|
years.
|
|
|
|
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.
|
|
comma placement...
Thanks to psy-fi for the head-up.
|
|
Reported by Bzzt_Ploink on IRC.
|
|
messagebox.
|
|
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.
|
|
|
|
We may use these for Wayland or SDL back-ends.
|
|
This reverts commit ff3cf93405e63fa367f64412bcfe96b382b24b38.
Turns out distros only a year old still use CMake 2.8x
|
|
This allows us to use newer features of CMake, and less hassles having to test & support older versions.
|
|
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.
|
|
Initialize glxew before glew,
so we can check whats supported before creating the context.
This also removes need for mxIgnoreNoVersion.
|
|
|
|
Differential Revision: https://developer.blender.org/D1539
|
|
Differential Revision: https://developer.blender.org/D1539
|
|
Order of initialization bug only impacted mesa's software-gl.
For now effectively revert support for glx-context-flags.
|
|
|
|
|
|
|
|
We had too many warnings lately... was awaiting that someone would kill them - didn't happen -> goes to my commit ratio! :P
|
|
|
|
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.
|
|
This regression was introduced in Blende 2.73a when we went through a
ghost context refactoring :(
|
|
|
|
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.
|
|
closer to the one requested on Windows.
Patch D1384 by Benoit Bolsee.
|
|
GHOST_ContextGLX was incomplete, ignoring profile-mask and profile-flags.
|