blender
/
blender
136
404
Fork 586
Code Issues 6.2k Pull Requests 753 Projects 19 Wiki Activity

Cleanup: spelling

This commit is contained in:
Campbell Barton 2021-07-01 10:25:17 +10:00
parent a689b5932d
commit 753806c731
3 changed files with 22 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
intern/ghost/intern/GHOST_SystemX11.cpp
View File

@ -1044,33 +1044,30 @@ void GHOST_SystemX11::processEvent(XEvent *xe)
GHOST_TKey gkey;
#ifdef USE_NON_LATIN_KB_WORKAROUND
/* XXX Code below is kinda awfully convoluted... Issues are:
*
* - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym
* is unmodified (or anyone swapping the keys with xmodmap).
*
* - XLookupKeysym seems to always use first defined keymap (see T47228), which generates
* keycodes unusable by ghost_key_from_keysym for non-Latin-compatible keymaps.
/* XXX: Code below is kinda awfully convoluted... Issues are:
* - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym
* is unmodified (or anyone swapping the keys with `xmodmap`).
* - #XLookupKeysym seems to always use first defined key-map (see T47228), which generates
* key-codes unusable by ghost_key_from_keysym for non-Latin-compatible key-maps.
*
* To address this, we:
*
* - Try to get a 'number' key_sym using XLookupKeysym (with virtual shift modifier),
* in a very restrictive set of cases.
* - Fallback to XLookupString to get a key_sym from active user-defined keymap.
* - Try to get a 'number' key_sym using #XLookupKeysym (with virtual shift modifier),
* in a very restrictive set of cases.
* - Fallback to #XLookupString to get a key_sym from active user-defined key-map.
*
* Note that:
* - This effectively 'lock' main number keys to always output number events
* (except when using alt-gr).
* - This enforces users to use an ASCII-compatible keymap with Blender -
* but at least it gives predictable and consistent results.
* - This effectively 'lock' main number keys to always output number events
* (except when using alt-gr).
* - This enforces users to use an ASCII-compatible key-map with Blender -
* but at least it gives predictable and consistent results.
*
* Also, note that nothing in XLib sources [1] makes it obvious why those two functions give
* different key_sym results...
* different key_sym results.
*
* [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c
*/
KeySym key_sym_str;
/* Mode_switch 'modifier' is AltGr - when this one or Shift are enabled,
/* Mode_switch 'modifier' is `AltGr` - when this one or Shift are enabled,
* we do not want to apply that 'forced number' hack. */
const unsigned int mode_switch_mask = XkbKeysymToModifiers(xke->display, XK_Mode_switch);
const unsigned int number_hack_forbidden_kmods_mask = mode_switch_mask | ShiftMask;

2
intern/ghost/intern/GHOST_WindowWin32.cpp
View File

@ -136,7 +136,7 @@ GHOST_WindowWin32::GHOST_WindowWin32(GHOST_SystemWin32 *system,
RegisterTouchWindow(m_hWnd, 0);
/* Register as droptarget. OleInitialize(0) required first, done in GHOST_SystemWin32. */
/* Register as drop-target. #OleInitialize(0) required first, done in GHOST_SystemWin32. */
m_dropTarget = new GHOST_DropTargetWin32(this, m_system);
::RegisterDragDrop(m_hWnd, m_dropTarget);

14
source/blender/blenkernel/intern/mesh_normals.c
View File

@ -715,7 +715,7 @@ void BKE_lnor_space_custom_normal_to_data(MLoopNorSpace *lnor_space,
const float custom_lnor[3],
short r_clnor_data[2])
{
/* We use null vector as NOP custom normal (can be simpler than giving autocomputed lnor...). */
/* We use null vector as NOP custom normal (can be simpler than giving auto-computed `lnor`). */
if (is_zero_v3(custom_lnor) || compare_v3v3(lnor_space->vec_lnor, custom_lnor, 1e-4f)) {
r_clnor_data[0] = r_clnor_data[1] = 0;
return;
@ -768,7 +768,7 @@ void BKE_lnor_space_custom_normal_to_data(MLoopNorSpace *lnor_space,
typedef struct LoopSplitTaskData {
/* Specific to each instance (each task). */
/** We have to create those outside of tasks, since afaik memarena is not threadsafe. */
/** We have to create those outside of tasks, since #MemArena is not thread-safe. */
MLoopNorSpace *lnor_space;
float (*lnor)[3];
const MLoop *ml_curr;
@ -924,7 +924,7 @@ static void mesh_edges_sharp_tag(LoopSplitTaskDataCommon *data,
* Define sharp edges as needed to mimic 'autosmooth' from angle threshold.
*
* Used when defining an empty custom loop normals data layer,
* to keep same shading as with autosmooth!
* to keep same shading as with auto-smooth!
*/
void BKE_edges_sharp_from_angle_set(const struct MVert *mverts,
const int UNUSED(numVerts),
@ -1481,11 +1481,11 @@ static void loop_split_generator(TaskPool *pool, LoopSplitTaskDataCommon *common
* If we find a new, never-processed cyclic smooth fan, we can do it now using that loop/edge
* as 'entry point', otherwise we can skip it. */
/* Note: In theory, we could make loop_split_generator_check_cyclic_smooth_fan() store
/* Note: In theory, we could make #loop_split_generator_check_cyclic_smooth_fan() store
* mlfan_vert_index'es and edge indexes in two stacks, to avoid having to fan again around
* the vert during actual computation of clnor & clnorspace. However, this would complicate
* the code, add more memory usage, and despite its logical complexity,
* loop_manifold_fan_around_vert_next() is quite cheap in term of CPU cycles,
* the vert during actual computation of `clnor` & `clnorspace`.
* However, this would complicate the code, add more memory usage, and despite its logical
* complexity, #loop_manifold_fan_around_vert_next() is quite cheap in term of CPU cycles,
* so really think it's not worth it. */
if (!IS_EDGE_SHARP(e2l_curr) && (BLI_BITMAP_TEST(skip_loops, ml_curr_index) ||
!loop_split_generator_check_cyclic_smooth_fan(mloops,