Separate custom text from display update
sragia opened this issue ยท 9 comments
Is your feature request related to a problem? Please describe.
Basically quite few people have asked me how to make sure that font stays the same after update and I have to say to them to not update Display. Issue is that it really restricts my (as WA author) ability to modify custom text. If I tell them to not update Display they won't get my fixes/new features shown, that could potentially even break aura if I lets say change some aura_env var I have defined in trigger or wherever. Looking at Display tab to me this is the main offender as something that WA author could change as everything else 99% of time is just visual and something that user is most likely to change.
Describe the solution you'd like
Extra toggle in update as I don't think it could be added to something else. Something like Display Texts or something. Also probably actual texts should be included too (text1 text2) as maybe with an update custom text is added not modified, so without %c user won't see it.
Describe alternatives you've considered
I mean alternative as author obviously could be %c1 %c2 in both texts (icon) and custom function
function()
return aura_env.text1, aura_env.text2
end
and change them in trigger or somewhere else (because you aren't always using custom trigger). And you probably will never need to update it.
but that's just workaround that complicates things
That seems like too narrow of an option. I see the problem, but we don't really have the room in that tooltip to add a category for every single addition like this.
I wouldn't be opposed to separating all custom scripts into one category (calling it Scripts
or Custom Code
), though. It would also be an opportunity to simplify the code surrounding custom scripts, too.
Yeah that's true for some auras tooltip starts to get a bit too crowded and overwhelming for user.
Custom Code update option probably is the best solution here. Especially when custom options exist and you don't really need/have auras with options in Init or some other custom code block.
@Stanzilla @InfusOnWoW @mrbuds do any of you have thoughts (specifically, objections) on this?
My first instinct to solve this involves extracting custom scripts out of the places they live currently, and placing them at a top level part of the aura data, and restructuring custom code support based on that.
This would solve a few issues:
- Whenever we add a new place that custom code can live, wago must update manually in order for users to view that code (and currently, I believe that a couple places like custom Condition Code are missing). Creating one collection where all custom code will be stored will allow @oratory to simplify the process of finding our codeblocks.
- About 150 lines of code in Transmission.lua (the code which finds custom code and allows the user to inspect it before importing) can be removed and replaced with about a 15 line loop.
- Updating auras which have custom code is a bit tricky at times, as this ticket demonstrates.
Sound good, i don't see it adding regressions.
If that can make things easier for transmissions, wago, and update tooltip for end-user it's nice.
I don't quite understand what your suggestion has to do with the original problem somehow. In my understanding the problem is that users want to keep their fonts but authors might want to change from %p to %c etc and those changes won't stick if people don't update the display category
My understanding was that the issue refers specifically to the code itself, and not the text which pulls from custom code.
I see your point, though. That can't be easily solved with the current update paradigm, I think.
Oh yeah, that's a bit of a pickle since what you proposed would lead to the %c code being preserved but then we could still into the problem I mentioned. I have no problem with the content of %c being moved from display to custom code but it might be not very transparent for users since technically it's still inside the display tab
Yup, I'm becoming increasingly convinced that the update tooltip just isn't sufficient on its own. There are just too many corner cases which erode its usefulness.
When first talking about it we were considering a setup wizard like experience for importing and updating so we could get rid of the tooltip once and for all, maybe when we go that route we can offer finer grained update options as well. I just really don't want to make it too complicated, the few options we currently have are already too much for some