Fix wordwrap setting leaking to other Ace addons & Optimization for AddLine - #86
Open
tflo wants to merge 2 commits into
Open
Fix wordwrap setting leaking to other Ace addons & Optimization for AddLine#86tflo wants to merge 2 commits into
AddLine#86tflo wants to merge 2 commits into
Conversation
Register separate widget for the lines
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):
With ChoreTracker loaded, often it looks like this:
Some more examples
The culprit is the wordwrap setting for the Ace Label in ChoreTracker/Modules/Display.lua, line 1160:
When released, the widget goes into the pool with wordwrap=false. Ace's
OnAcquirefunction 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):
The symptoms are intermittent:
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, viaCreateControl(v.dialogControl or v.control, "Label")in thedescription’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
AddLinefunction, I also moved theSetWordWrapfromAddLineto the widget’sOnAcquire.)An alternative solution would be to just clean up when releasing…
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
SetWordWrapis 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
AddLinecall, we use a predefined fontobject ('ChoreTrackerLineFont') that only changes when the config is changed. InAddLinewe just associate it with the fontstring. The size of the fontstring is only modified when needed (SetFontHeight), i.e. if thesizearg is provided with header lines.In essence, this saves one
self.fontObject:SetFont(font, height, flags)call for eachAddLinecall (see AceGUIWidget-Label.lua, line 131).