Skip to content

Fix wordwrap setting leaking to other Ace addons & Optimization for AddLine - #86

Open
tflo wants to merge 2 commits into
ThingEngineering:mainfrom
tflo:main
Open

Fix wordwrap setting leaking to other Ace addons & Optimization for AddLine#86
tflo wants to merge 2 commits into
ThingEngineering:mainfrom
tflo:main

Conversation

@tflo

@tflo tflo commented Sep 3, 2026

Copy link
Copy Markdown

Commit 1: Fix wordwrap setting leaking to other Ace addons

This is some arbitrary description text in a config panel of an Ace addon (SilverDragon, could be any):

SDM_0

 
With ChoreTracker loaded, often it looks like this:

SDM_1

 

Some more examples EA_1 HN_1 SD1 MP_1 TLM_1 AIO_1

The culprit is the wordwrap setting for the Ace Label in ChoreTracker/Modules/Display.lua, line 1160:

function Module:AddLine(frame, text, size, waypointFunc)
    local label = AceGUI:Create('Label')
    -- some stuff
    label.label:SetWordWrap(false) -- XXX
    -- some stuff
end

When released, the widget goes into the pool with wordwrap=false. Ace's OnAcquire function resets the things that are settable via the widget's methods, e.g. text, size, color, justification, etc. But it does not reset the wordwrap. (AceGUIWidget-Label.lua, line 71)

Basically, what happens is this (from AceGUI-3.0.lua, line 6):

When using AceGUI-3.0 directly, please do not modify the frames of the widgets directly, as any "unknown" change to the widgets will cause addons that get your widget out of the widget pool to misbehave.

The symptoms are intermittent:

  • Not all Ace addons are affected at the same time.
  • Opening/closing a config panel may “fix” it, or vice-versa.

If or when an addon picks up a corrupted widget from the pool is undetermined. Ironically, ChoreTracker itself is “immune”, as its config panel doesn’t seem to have any long lines ;)

How does the wordwrap from ‘Label get into ‘description’ texts?

It took me a while to figure this out, since most of the addons with the mis-wrapping texts don’t (explicitely) use a Label widget for it.

Taking the SilverDragon example again:

The text from the first screenshot is set with type = "description" (SilverDragon/config.lua, line 16 and 41). The ‘Label’ type comes in through the backdoor, via CreateControl(v.dialogControl or v.control, "Label") in the description’s definition (AceConfigDialog-3.0.lua, line 1401), where ‘Label’ is the fallback type if no control widget is set.


The solution I suggest is to register a separate ‘ChoreLabel’ widget type, which inherits from the Label type but does not contaminate the widget pool.

(Since 'ChoreLabel' is only used for the AddLine function, I also moved the SetWordWrap from AddLine to the widget’s OnAcquire.)

An alternative solution would be to just clean up when releasing…
function Module:AddLine(frame, text, size, waypointFunc)
    local label = AceGUI:Create('Label')
    -- some stuff
    label.label:SetWordWrap(false)
    label:SetCallback('OnRelease', function(widget) widget.label:SetWordWrap(true) end)
    -- some stuff
end

But it seems more proper to me to use a dedicated widget type, similar as you’ve done with ChoreFrame.lua.


Commit 2: Optimize fontstring construction

This could also be a separate PR. I just put it here, because it modifies the same file and function (AddLine)

While trying to figure out the wordwrap leak, my first suspicion was that it is propagated through a fontobject, so I defined a separate one. This turned out to be wrong, as SetWordWrap is a fontstring-only method, not for fontobjects.

But I stil think the optimization is worthwhile, because it significantly reduces the fonstring-related calls for each line:

Instead of redefining the fontobject with each AddLine call, we use a predefined fontobject ('ChoreTrackerLineFont') that only changes when the config is changed. In AddLine we just associate it with the fontstring. The size of the fontstring is only modified when needed (SetFontHeight), i.e. if the size arg is provided with header lines.

In essence, this saves one self.fontObject:SetFont(font, height, flags) call for each AddLine call (see AceGUIWidget-Label.lua, line 131).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant