rB870440dee910c9 just did NULL-check for Main pointer, actual issue is
that bContext pointer was NULL. This can be fixed by ensuring
PROP_ENUM_NO_CONTEXT flag is not set by calling
WM_operator_properties_sanitize when creating RNA buttons. Now, layout
previews are visible in keymap editor too.
For Windows 8.1 and X11 (Linux, BSD) now use the DPI specified by the operating
system, which previously only worked on macOS. For Windows this is handled per
monitor, for X11 this is based on Xft.dpi or xrandr --dpi. This should result
in appropriate font and button sizes by default in most cases.
The UI has been simplified to a single UI Scale factor relative to the automatic
DPI, instead of two DPI and Virtual Pixel Size settings. There is forward and
backwards compatibility for existing user preferences.
Reviewed By: brecht, LazyDodo
Differential Revision: https://developer.blender.org/D2539
A user doesn't want to necessarily create a new Screen only because she
wants a new window.
This patch allows the user to pick the screen to use for the new Window.
If the screen picked is the active one, it duplicates it (as the old
behaviour in Blender).
Patch with contributions and fixes by Julian Eisel (Severin)
Subscribers: venomgfx
Differential Revision: https://developer.blender.org/D2555
Basically all this does is drawing layout previews into the opened layout search menu.
https://youtu.be/RHYWtZP7pyA
The previews are drawn using offscreen rendering so they can't use multi-threading (yet!). But that shouldn't be an issue since only a handful of previews are drawn at the same time. Normally we only need to redraw the preview if a screen layout was changed. Would be nice if PreviewImage could store if it supports threaded rendering.
Previews are saved in files, might be useful if you later want to support appending layouts.
Adds a new file screen_draw.c.
Changing virtual pixelsize only had an affect when a second window was open. (Was also possible to trigger update by opening another window.)
Steps to reproduce:
* Change any editor into user preferences *in main window*
* Change virtual pixel size -> nothing happens
Steps to reproduce fixed glitches were:
* Change any editor to be file browser from menu, Ctrl+O *from the file browser area*, Esc -> area reset to what it was before changing to file browser initially
* Ctrl+O from any area, F12, Esc -> returns to initial editor in full-screen (expected is file browser in full-screen)
Fixes T46229
Core of the fix is removing old area from spacedata list when going back to previous area (see ED_area_prevspace -> BKE_spacedata_remove). Also, when creating a new temp area we now don't exit old area anymore (needed so SpaceFile->op is kept, but it also makes sense in general)
Aaand finally removes some ugly hacks.
Tested quite a bit, so I think it's safe to apply (besides of remark below), just would like to get things double checked and confirmed. After all, this full-screen stuff finally starts to feel like it's working :P
Note, there's still a memory leak when quitting Blender with temp area open. Haven't found out how to solve yet, but it's not that important for review anyway.
Reviewers: campbellbarton, brecht
Reviewed By: brecht
Subscribers: plyczkowski, Blendify
Maniphest Tasks: T46229
Differential Revision: https://developer.blender.org/D1531
Opening a tmp window on a 4K display with virtual pixelsize set to double results in a too small window. For Retina this seems to be handled on GHOST level already, so multiply by virtual pixelsize only.
Calling event handling recursively during window live resize is problematic,
the code wasn't designed to do that. Instead postpone event handling until
after live resize.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
This basically does the 'timer' part of Jobs system: it sends a given notifier on every timer step.
This is needed for background tasks (not full-fledged jobs, lighter BLI_tasks based) that want to update UI
(like for up-comming new thumbnail handling in filebrowser).
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
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
* Revert 776bfa64a5 and c3dad7953a (some X11 systems are doing
stupid things forcing me to do an extra check that completely breaks the
click type handling on other systems using the slightly changed
implementation from those commits - see T44278)
* Fix sample lines in Compositor+VSE
(And yes, this time I tested on both of my systems to make sure
everything is fine)
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
Just add KM_CLICK to the already sent KM_RELEASE, don't send a new one
for this.
This might help us to get rid of quite some glitches and workarounds \o/
(why didn't this come earlier to my mind? :S)
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
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?
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!
