[Plugin] LordOfTheToolbars - v4.2a - 21 Oct 26

[juju]

@fredo6 said:

For Muzwalls, I think this is due to the late loading of the plugin. So, LOTT cannot catch them at startup.

Is there no load delay option that can be done? Or perhaps advise for MuzWalls authors how to get it to load faster and checking of licensing? There are other extensions that also have to load and check licensing that do seem to load fine.

@fredo6 said:

For custom toolbars, I can check, but I think you have to restart Sketchup to see the changes.

I've tried restarting inbetween, it doesn't make a difference, changes do not reflect once the custom toolbar was actualised (ticked) to show on screen, even if you switch it off and switch it back on later.

[fredo6]

Custom toolbars cannot be updated once on screen. This is because toolbars in Sketchup are not editable. I think LOTT can just add new icons.
Normally, at next restart, the custom toolbars should show as designed.

For Muzwalls, I have to check what is the real issue.

[rv1974]

In SU26 + latest LOTT I can't move the nether palettes, nor rosette (hope I call them right). unlock - lock, nothing helps. LOTT stuff stuck in the middle of viewport and cause lots of troubles

[rv1974]

luckily Claude fixed it on my end:
Here’s a bug report you can send to Fredo6. It’s written in his terms, so he can go straight to the code:

Subject: LOTT palettes can’t be dragged in SketchUp 2026 (Windows): body_move_start fires, but body_move_perform is never called

Environment

SketchUp 2026, version 26.2.243, Windows (Qt build), display scaling 100%, two monitors (the second is to the left of the main one, so it has negative x)
Lord of the Toolbars 4.2a (21 Oct 26), LibFredo6 16.3b (21 Oct 26)

Symptoms

Floating palettes (Traductor::ChromiumWdlg, mini-title style) can’t be dragged, either by the mini title bar or by an empty area of the body.
Because they can’t be moved, the stored position stays wherever the palette first opened (the centre of the screen). So every new session the palette comes back in the centre.

What I traced (by wrapping the ChromiumWdlg methods at runtime)

On mouse down over MINITITLE__div_text or THE_WDLG_BODY:
mini_title_event("onMouseDown") → body_move_apply → body_move_start returns true, and @body_moving = true
@body_move_initial_mouse_pos and @body_move_initial_dialog_pos are set correctly
While dragging, the page keeps sending events, about 60 per drag:
mini_title_event("onMouseDrag", "", "MINITITLE__div_text", "x,y,0")
mini_title_event("wposition", …) → notify_size_position
body_move_perform is never called. No true_set_position or set_position either, so the window never moves. No exceptions are raised.
On onMouseUp, body_move_stop is not called either, so @body_moving stays true after the release.
Calling wdlg.set_position or true_set_position from Ruby moves the window fine, including to negative x on the second monitor. So the move itself works; only the drag path never triggers it.

Lock state inconsistency

After unlocking with Manager#palette_lock_from_icon, Manager#palette_locked?(sym) returns false and the palette hash has :locked => false. But ChromiumWdlg#body_move_locked? on the same palette still returns true.
body_move_set_locked(false) didn’t change that.
So the window-level lock flag isn’t synced with the palette’s :locked setting.
The lock icon also sits right at the end of the thin mini title bar, so it’s easy to lock a palette by accident while trying to drag it.

Two position records

LOTT’s own palette data (:left/:top, in LibFredo6_LOTT_SU2026.dat) and the HtmlDialog geometry vault (LibFredo6_HtmlDialog_SU2026_RT100.dat, xleft/ytop) hold different values for the same palette.
Example for the same palette:
LOTT data: -301, 13
vault: -216, 663
actual window: -187, 663
SketchUp’s own WebCommonDialog_LOTT_* entry in PrivatePreferences.json has yet another value.
It’s worth checking which one wins on restore.

Workaround I’m using (proves the rest of the chain works)

A small patch prepended to Traductor::ChromiumWdlg:

body_move_start: if the palette isn’t locked according to Manager#palette_locked?, it remembers GetCursorPos and @body_move_initial_dialog_pos.
mini_title_event("onMouseDrag"): it calls true_set_position(initial_dialog_pos + (GetCursorPos − initial_cursor)).
mini_title_event("onMouseUp"): it calls body_move_stop, sets @body_moving = false, then calls Manager#palette_register_position(sym, x, y) and store_position_by_sketchup_window.

With this, palettes drag smoothly and the new position is stored in the LOTT data.

Side note: GetAsyncKeyState(VK_LBUTTON) reported the left button as not pressed during these drags. If the native move code polls the mouse button state, that would explain why it never moves.

Requested fixes

Call body_move_perform (or the equivalent window move) on onMouseDrag while @body_moving is set, and don’t rely on polling the mouse button state.
Call body_move_stop on onMouseUp so the move ends and the position is saved.
Keep ChromiumWdlg#body_move_locked? in sync with the palette’s :locked flag when it is locked or unlocked.
Optional: move the lock icon away from the drag area, or ask for confirmation, to prevent accidental locking.

It’s in English since that’s what he uses. If it’s for his forum thread, you could also attach LOTT_DragFix.rb from your Plugins folder as a working reference.

[fredo6]

I am not sure I understand everything.

1. Can you move a palette interactively or not?

2. Do you want palettes to stay on a different monitor than the one where Sketchup is?

3. Was evrything working fine before you upgraded to LOTT v4.2 and LibFredo6 v16.3b?

4. You said that Claude fixed it (I don't know how, but why not). Do you still have the problem?

[rv1974]

1. no, before the fix - no. with the fix - yes. before the fix i was able to stretch the left side then another - thus it was "moving" in a pervert way. after the restart my palette was in the center.
2. for years i keep my palette on the 2nd monitor keeping SU viewport 100% pure.
3. yes
4. it's solved on my end by adding the fix, but ideally i'd prefer be fixed in the LOTT itself

[fredo6]

Then, I can probably manage. I think the older versions was not forcing the palettes to be on the same monitor as Sketchup.

By the way, what is the form of the Claude fix?

[rv1974]

@fredo6 stand alone rb file. would you like to get it?

[panixia]

@fredo6 according to GPT the Claude script is most likely some sort of sniffing of the LOTT calls implemented using "Module#prepend" while they are executed with some monkey patching going on after that.
Interesting technique to fix small stuff "on the fly" but I fear is not very robust (what happens if you change the code on your side? any script created with this technique would quickly fall apart, I guess).

[rv1974]

@panixia said:

Interesting technique to fix small stuff "on the fly"

well i had 3 alternatives: throw LOTT entirely (after years of using), this failed state patch, or vibecoding a new Temu LOTT from scratch

[panixia]

@rv1974 said:

vibecoding a new Temu LOTT from scratch

I'm pretty sure @alexpacio2013 already did something like that