Description

The title may be slightly misleading, but not sure how else to frame it.

I was reorganizing my WAs after nested group support was added (hurray!) - for example, I have a group called "Class WAs", that has a subgroup for each class (Monk, Rogue, etc), and within those class-specific subgroups, I have e.g. Luxthos/etc groups.

What I noticed was, after I got toward the end of reorganization - i.e., once there were a good number of auras (transitively speaking) under the outermost "Class WAs" group - the WA screen just disappeared. No more previews, no aura list, etc - I had to hit escape for it to exit the WA config, at which point my normal UI worked again.

Since it remembers what groups were open/focused, attempting to /wa again would cause the screen to blank. I had to /reload to get it to reset the WA config UI state in order to see unloaded auras/previews/etc again.

What I suspect is happening is that there is an upper bound on the number of auras that can be previewed (obviously I don't want to preview all class WAs together, that would be madness) and so WA just bailed. I turned Lua errors on and do not see any errors being reported. I'm not sure if there are even logs that can be provided in this case. (I'm happy to do so if someone can tell me how.)

So, my questions is: is this intended? Is the expectation that previews will be shown regardless of nesting level, or should it possibly prevent previewing a group if it only consists of subgroups? I can flatten my WA structure if necessary, but I wonder if it would be better to change it so that it will only preview a group if at least one of that group's children is an aura (rather than attempting to recursively preview everything in a group).

Thoughts? Happy to provide any info you'd like!

WeakAuras Version

WeakAuras 4.0.0

World of Warcraft Flavor

Retail (Default)

Tested with only WeakAuras

• Yes
• No

Lua Error

No Lua errors.

Reproduction Steps

1. Create a top-level group
2. Add subgroups for each class
3. Add Luxthos WAs (core + dynamic + utilities) for each class in their subgroup
4. Attempt to click on the top-level group
5. sadness

Last Good Version

n/a

Screenshots

Export String

WeakAuras.zip

It's been an issue for a very long time, nested make it a bit more apparent because peoples make bigger group.

Currently when you select a group and go to a tab that is not the group tab, it will allow you to edit all auras contained in it, for example the display tab edit the display tab of all your auras. Taking and comparing the options of all those auras is slow.

It's been an issue for a very long time, nested make it a bit more apparent because peoples make bigger group.

Currently when you select a group and go to a tab that is not the group tab, it will allow you to edit all auras contained in it, for example the display tab edit the display tab of all your auras. Taking and comparing the options of all those auras is slow.

Yeah, that makes sense - prior to this issue I hadn't really thought about merged option editing or anything like that. Since that's historical behavior that (I assume) you want to preserve, agree that it makes it more complicated, and it makes sense why this would be more pronounced with nested groups.

That's why I thought maybe having some basic heuristic (like, "this group consists only of subgroups") to classify groups into "functional/non-functional" - or maybe adding a new "optionless" group type - would be a sane way to control whether you situationally bothered to do anything with options, based on group context, which could(?) be a nice optimization, assuming it was in line with whatever design goals you have for groups in general.

This is all predicated on guessing (I may be totally wrong) that users will start to use groups more and more for organizational (rather than purely functional) purposes as time goes on, because WA organization is pretty ad hoc atm (and also depends a lot on authors, who all have completely different organizational/naming styles themselves, etc).

There's a limit on how long lua scripts that is enforced by wow. How many auras are needed to cause that depends on the computer.

It's not advisable to put essentially all your auras into one group.

Good to know. I think the question at the end is still valid, though: if WAs are being eagerly loaded/previewed irrespective of depth that feels suboptimal, and it might be worthwhile to consider the suggestion.

The problem is not showing all auras, the problem is building the merged options. So your suggestion would not solve any problem.

Yeah, I guess I was suggesting more robust group support. Nevermind. Thanks!

Fixing the problem requires rewriting a gigantic amount of code, which we have to tackle. But your suggestion has nothing to do with that.

Not sure if you're referring to general optimizations or lazy loading or some other architectural change, but I was trying to start a discussion about it. I'll leave it alone, but as general feedback, please consider fostering discussion instead of shutting it down immediately in the future.