Commit: 753806c731b6e8b9de5f2af29ff6235b0590ab6c
Author: Campbell Barton
Date: Thu Jul 1 10:25:17 2021 +1000
Branches: master
https://developer.blender.org/rB753806c731b6e8b9de5f2af29ff6235b0590ab6c
Cleanup: spelling
===================================================================
M intern/ghost/intern/GHOST_SystemX11.cpp
M intern/ghost/intern/GHOST_WindowWin32.cpp
M source/blender/blenkernel/intern/mesh_normals.c
===================================================================
diff --git a/intern/ghost/intern/GHOST_SystemX11.cpp
b/intern/ghost/intern/GHOST_SystemX11.cpp
index 2b1069f9acc..c5564e9880e 100644
--- a/intern/ghost/intern/GHOST_SystemX11.cpp
+++ b/intern/ghost/intern/GHOST_SystemX11.cpp
@@ -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;
diff --git a/intern/ghost/intern/GHOST_WindowWin32.cpp
b/intern/ghost/intern/GHOST_WindowWin32.cpp
index 4f85e2ea8d0..1b73b765b49 100644
--- a/intern/ghost/intern/GHOST_WindowWin32.cpp
+++ b/intern/ghost/intern/GHOST_WindowWin32.cpp
@@ -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);
diff --git a/source/blender/blenkernel/intern/mesh_normals.c
b/source/blender/blenkernel/intern/mesh_normals.c
index 02f21cf1b24..9f09ce46e11 100644
--- a/source/blender/blenkernel/intern/mesh_normals.c
+++ b/source/blender/blenkernel/intern/mesh_normals.c
@@ -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,
_______________________________________________
Bf-blender-cvs mailing list
[email protected]
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-blender-cvs
