Summary
The "Loading…"/"Searching…" spinner that sometimes appears in Nemo's floating bar is gated by a hardcoded 500 ms delay, and the spinner's size/margins are also hardcoded magic numbers. This is exactly why the indicator only sometimes appears: if a folder finishes loading within 500 ms the timer is cancelled and the spinner is never shown; only slower loads make it appear.
Where the hardcoding is
src/nemo-window-manage-views.c, function setup_loading_floating_bar():
slot->loading_timeout_id =
g_timeout_add (500, setup_loading_floating_bar_timeout_cb, slot);
The timeout is later cancelled in remove_loading_floating_bar() (called from end_location_change() on nemo_window_report_load_complete()), so the spinner only appears when loading takes longer than this value. The literal 500 is the debounce that decides whether the indicator shows at all.
In src/nemo-floating-bar.c, the spinner geometry is also hardcoded:
gtk_widget_set_size_request (w, 16, 16); /* line 232 — 16x16 px */
gtk_widget_set_margin_left (w, 8); /* line 233 — 8 px */
"spacing", 8, /* line 337 — 8 px */
Why it matters
The rest of the codebase consistently names such delays as #define constants, e.g. LOADING_TO_EMPTY_DELAY 100 (nemo-list-model.c), DRAG_EXPAND_CATEGORY_DELAY 500 (nemo-places-sidebar.c), UPDATE_INTERVAL_TIMEOUT_INTERVAL 500 (nemo-view.c), SCROLL_TIMEOUT 150 / INITIAL_SCROLL_TIMEOUT 300 (nemo-pathbar.c), and CHOWN_CHGRP_TIMEOUT 300 /* milliseconds */ (nemo-properties-window.c). The bare 500 / 16 / 8 literals are inconsistent with this convention, making the loading-indicator behavior harder to locate, tune and unit-test.
Suggested fix
Introduce a named constant, e.g. #define LOADING_FLOATING_BAR_TIMEOUT 500 /* milliseconds */ in src/nemo-window-manage-views.c, and use it in the g_timeout_add call. Likewise expose the spinner size/margins as named constants or via CSS. No behavior change is required — just naming the existing magic numbers so the "sometimes appears" debounce is explicit and consistent.
Environment
- Nemo source: 6.0.2 (linuxmint/nemo)
- Files:
src/nemo-window-manage-views.c (line 1269), src/nemo-floating-bar.c (lines 232, 233, 337)
This is a code-quality/hardcoding issue; runtime behavior is otherwise correct.
Summary
The "Loading…"/"Searching…" spinner that sometimes appears in Nemo's floating bar is gated by a hardcoded 500 ms delay, and the spinner's size/margins are also hardcoded magic numbers. This is exactly why the indicator only sometimes appears: if a folder finishes loading within 500 ms the timer is cancelled and the spinner is never shown; only slower loads make it appear.
Where the hardcoding is
src/nemo-window-manage-views.c, functionsetup_loading_floating_bar():The timeout is later cancelled in
remove_loading_floating_bar()(called fromend_location_change()onnemo_window_report_load_complete()), so the spinner only appears when loading takes longer than this value. The literal500is the debounce that decides whether the indicator shows at all.In
src/nemo-floating-bar.c, the spinner geometry is also hardcoded:Why it matters
The rest of the codebase consistently names such delays as
#defineconstants, e.g.LOADING_TO_EMPTY_DELAY 100(nemo-list-model.c),DRAG_EXPAND_CATEGORY_DELAY 500(nemo-places-sidebar.c),UPDATE_INTERVAL_TIMEOUT_INTERVAL 500(nemo-view.c),SCROLL_TIMEOUT 150/INITIAL_SCROLL_TIMEOUT 300(nemo-pathbar.c), andCHOWN_CHGRP_TIMEOUT 300 /* milliseconds */(nemo-properties-window.c). The bare500/16/8literals are inconsistent with this convention, making the loading-indicator behavior harder to locate, tune and unit-test.Suggested fix
Introduce a named constant, e.g.
#define LOADING_FLOATING_BAR_TIMEOUT 500 /* milliseconds */insrc/nemo-window-manage-views.c, and use it in theg_timeout_addcall. Likewise expose the spinner size/margins as named constants or via CSS. No behavior change is required — just naming the existing magic numbers so the "sometimes appears" debounce is explicit and consistent.Environment
src/nemo-window-manage-views.c(line 1269),src/nemo-floating-bar.c(lines 232, 233, 337)This is a code-quality/hardcoding issue; runtime behavior is otherwise correct.