| Age | Commit message (Collapse) | Author |
|---|
|
Also replace integer with bool in Ghost API when only used as boolean,
and uint8* with char* in Ghost API when variable is a string.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11617
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
|
|
This patch extends D11695 to provide full support for Chinese and Korean
input on macOS.
Chinese input notes:
You can input symbolic characters (such as '! , '$') during Chinese input.
The difference from Japanese input is that multiple `insertText` may be
called with a single key down (`keyDown` method). This happens when you input
a symbolic character (such as '! , '$') during conversion.
The conversion is confirmed (`insertText`) and the symbolic character is
entered (`insertText`). To solve this problem, I have `result_text` to
concatenate the strings and store them in `result`.
Korean input notes:
Korean does not display a conversion suggestion window.
Like Chinese, Korean input may call multiple `insertText` methods. Also,
in Korean, the previous confirmation (`setMarkedText` and `insertText`) and
the next conversion is processed (`setMarkedText`) may be called
simultaneously with a single key down (`keyDown` method).
For example:
1. press g ㅎ (`setMarkedText`)
2. press k 하 (`setMarkedText`)
3. press t 앗 (`setMarkedText`)
4. press k 하세 (`setMarkedText`, `insertText`, `setMarkedText`)
Fixed so that the `insertText` and the last `setMarkedText` are processed.
Also, if a control character (such as Arrow, Enter) is input during Korean
input, the conversion will be confirmed (`setMarkedText`, `insertText`) and
the original control character will be processed.
In other words, if you press the left arrow key while typing in Korean, the
cursor will move to the left after the character is confirmed. Therefore, I
modified the `keyDown` method so that the `handleKeyEvent` is called again
after the `insertText` is processed in the `interpretKeyEvents` method.
Differential Revision: https://developer.blender.org/D11699
|
|
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
|
|
This revision replaces the deprecated protocol NSTextInput with
NSTextInputClient in Cocoa Text View. No functional changes.
For more information of the methods, please see:
https://developer.apple.com/documentation/appkit/nstextinputclient
Differential Revision: https://developer.blender.org/D11407
|
|
Similar code is found in Apple's code samples.
Differential Revision: https://developer.blender.org/D11434
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
In the Win32 platform our setTitle() can properly assign a Unicode
utf-8 window title. Unfortunately our getTitle() will only read regular
8-bit character strings. This means that we can never compare what we
set to what we get. This patch updates getTitle() to use Unicode-aware
GetWindowTextLengthW and GetWindowTextW.
see T88909 for an example of this affecting user experience.
Differential Revision: https://developer.blender.org/D11782
Reviewed by Ray Molenkamp
|
|
|
|
|
|
When using multiple monitors that differ in scale and/or dpi, the
varying sizes of the window titles and borders can cause the placement
of those windows to be out by a small amount. This patch adjusts for
those differences on Windows 10 and newer.
see D10863 for details and examples.
Differential Revision: https://developer.blender.org/D10863
Reviewed by Ray Molenkamp
|
|
This is just some cleanup of the Win32 window creation code. After
CreateWindowExW() this patch uses some early exits to replace some
potentially confusing if blocks. No functional changes.
Differential Revision: https://developer.blender.org/D11446
Reviewed by Ray Molenkamp
|
|
When a window is left with a WinPointer pen, the inrange check
prevents resetting pen info.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Mark either all or no class methods with override
* Don't use zero sized array since it has a different size in C and C++.
Using a little more memory here is not significant.
* Don't use deprecated mechanism to mark private GSet members in clang
just like we don't for MSVC, it warns even for simple zero initialization.
|
|
|
|
|
|
|
|
Iteration was incorrectly calling the same object. Had it called every
window it would still be unnecessary as WM_DISPLAYCHANGE is sent to all
broadcast receiving windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
|
|
|
|
Also use full sentences, and correct typos.
|
|
against system input.
Reviewed By: brecht, LazyDodo
Maniphest Tasks: T88852
Differential Revision: https://developer.blender.org/D11508
|
|
|
|
ChildWindowFromPoint retrieves the child of the provided window at a
point. In this case it always returns 0 because HWND_DESKTOP is flag
defined as 0, which is never a valid window handle and is not intended
for use in place of a window handle.
Forwarding of mousewheel events was added in adb08def613d, and later
modified to the current unworking state in e9645806f563. Sending mouse
wheel events to the window under the cursor is a system preference and
therefore should not be overridden by Blender, therefore the noop code
has been removed.
|
|
Also remove reference to function that never existed for adding `bNode`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Wayland server will not update hidden surfaces. This will block the
main event loop and thus also block updates to visible windows in a multi-
window setup.
|
