Prat 3.0

Prat 3.0

26M Downloads

What is the expected behaviour, for the alpha on chat windows?

plusmouse opened this issue ยท 11 comments

commented

@Daeveren

Well you do need to have both because either the changes in Prat settings affect only 'chat frame 1' (and then the user controls the other chat frames via Blizz chat tab menu), either Prat settings controls all the chat frames with just 1 value for all the frames (and then the user can't have different background transparencies for different chat frames) - if you ask me, I think neither of these is ok. Alternatively, Prat Frames setting would let the user select different values for each Chat Frame (ideally they'd be also linked to the background alpha value that is changeable from the Blizz chat background setting).

Latest change you did fixed (again) the ability to have individual background values per chat frame (which is fine for me, no need to open a new issue - it's just unfortunate that this feature stopped working with various alpha versions). Except that the thing I notice now is that the alpha values now from Prat and from chat tab UI work additive so to say - as in, after last alpha version, setting chat UI to "100% alpha" + Prat to 50% makes the chat background actually reach 50% background; setting both of them to 50% results in actual 25% background; setting Blizz alpha to 0% and Prat to 50% result in actual full transparency (0% alpha); in order to have a black background now the user has to set both of them at 100% (setting Prat to 100% does not make background black unless the chat background setting is also at 100%). These things feel pretty wrong and confusing to the user so at minimum I believe you should add a disclaimer in the Prat > Frames page, informing the user to make sure they check the Blizz alpha value too. This also has the potential to disrupt everyone's UI once they update to the next stable Prat build, because their background transparency value has just changed (ie: mine was 50% for chat frame 1, after updating to latest alpha it was too transparent and it required playing with both alpha values and comparing to my past screenshots in order to set to a similar background value).

I'm fine with any approaches, as long as individual chat frames can have separate background transparency (which worked before and works now too after the fix).

About the post earlier "The chat will now have a constant alpha value when the frames module is enabled, no fading away or fading in." really for the sake of clarity of the users that do not read this github page - I think that the option should be under a "enable/disable darken on mouseover" (or whatever the choosed name) or atleast inform them in some way that Prat has lost the ability to darken the chat frames on mouseover. Having it always 'disabled' might be confusing for some or could also be frustrating to others - think of the ones that have the chat window at full transparency (0% alpha) and that were using the "darken on mouseover" to find their actual chat frame size or to read text that would otherwise be hard to read with fully transparent background.

Whether you think it's best to open a new issue on github or keep this thread, well, it's up to you.

Originally posted by @Daeveren in #46 (comment)

commented

As someone who used prat for ages and loved the feature to completely hide the on hover background texture, I was happy a few days ago when one of the versions hid it again. Now its gone again. And Im using only one profile. The fix was there from my point of view. If you could offer it as a seperate module for us "one profile users" that would be great.

commented

Ah, I didnt see this new option when I updated to the latest version today. Thank you.

commented

@Zasz333 See #59 and use the referenced option. Then when you set your chat to fully transparent it will remain that way, even when moused over.
image

commented

I felt that getting a clarification of the want the alpha state was necessary because several of the reports about the alpha value all had differing views on what the alpha value behaviour should be.

It sounds like Prat needs its chat window settings updating, and that having one value for all isn't enough configurability.

Blending the alpha values is the best way I could think of making sure the alpha from both settings were taking into account without updating the configuration UI - priority at the moment is getting Prat working taint free, so updating the UI would have to be a future feature.

commented

So not sure what is going on with the addon currently but there was a big update the other day that broke background alpha and you had to reset the setting every time you logged into the game and then today there was another update and now you can't set background alpha at all.

Things were better with the mod before the first big update. Can we get something worked out with this alpha setting issue? The mod is basically unusable for me currently in this state.

Actually based on further reading I was able to find a setting to get the frames to not fade with alpha settings which works just fine.

commented

The alpha issue is tricky because the previous way caused errors in edit mode.

Its complicated by the fact that I'm not sure what the right way for it to work is. So far I've read comments wanting the following:

  • Wanted background fully transparent
  • Wanted all chat windows to have the same alpha
  • Wanted all chat windows to have individually configurable alpha and colour via Blizzard UI, but still let the Prat options do something.

Ended up making a solution that happened to be able to do everything without adding more config options, but its resulted in confusion.

If you could explain what you want from the alpha setting I can use that to help figure out what the right solution is.

commented

If you could explain what you want from the alpha setting I can use that to help figure out what the right solution is.

People expect addon to respect the background alpha set in the chat settings (right click on chat tab menu), this is why it's confusing now that Prat uses a separate, but additive alpha setting. The change from a few days ago broke everyone's UI (it changed their background transparency), despite them not doing anything (worst part is they don't even have a clue what happened). People will look in confusion and some will come here and open issues - but only few of them who figure out it's from Prat (as usual, most of people likely blame Blizzard for the mess and move on).
If the code won't be changed so that the alpha setting in Prat adjusts the same value as default UI, then atleast give people a warning at login in chat so that they know what's going on. But long term I think you should just think in making a separate Prat module responsible with the chat background changes, so that people can chose to enable or disable it.

commented

Yep. Agreed. So I've removed the option, as the help requests were all about getting a specific alpha, not controlling the fade in/out.

commented

Yep. Agreed. So I've removed the option, as the help requests were all about getting a specific alpha, not controlling the fade in/out.

There is one fellow player who requested that fade thing, but in my personal oppinion, I think that whatever feature affects the fade be added as a separate toggle ("disable mouseover background darkening" or something like this) and not tie it to the alpha setting slider.
Either way, thank you for being so involved with the development of this addon.

commented

Yeah the one wanting it not reacting to mouseover would be me, creator of that issue.
I went back to "Prat-3.0-3.9.5.zip" just to get the option back after updating to latest.

Anyhow i read through other problems you got from that "fix" not being able to change alpha on different chat windows? I run "Prat-3.0-3.9.5.zip" right now with different alphas and they all stick after a reload.
Or was it that you wanted different alphas for mouseover?

commented

Yeah the one wanting it not reacting to mouseover would be me, creator of that issue. I went back to "Prat-3.0-3.9.5.zip" just to get the option back after updating to latest.

Anyhow i read through other problems you got from that "fix" not being able to change alpha on different chat windows? I run "Prat-3.0-3.9.5.zip" right now with different alphas and they all stick after a reload. Or was it that you wanted different alphas for mouseover?

Due to how that thing got implemented, the alpha slider in Prat was functioning as a separate alpha than the one you can set in the chat tab right click menu. This was not the main issue itself, but because of how this was added, it changed everyone's chat background opacity to a different value, for all their chars (making it less transparent than it was before). Not only this, but in order for players to bring it back to how it was before that Prat version, they had to play a guessing game with both alpha values until they reached something that resembled what they had before. Virtually everyone (except the few souls that wander the github Issues section of Prat) were taken by surprise by the changes to their UI. Even when one would go through the hassle of making the background opacity back to how it was, they'd have to do that for each of their chars. This also affected me, but I went on and used the extra stuff > memory > load settings feature of Prat in order to transfer the settings from one char to another - but this was possible because I was fine with having the same background values on all my alts; if someone had different alpha values for each of their alts, then they had to readjust each of their chars.

I do think that the mouseover thingie is valid, I just hoped it would be added as an optional toggle and not force it on everyone - for example, it's a pain to deal with multiple transparent chat windows without a mouseover darken enabled, because you can't see the chat frame contour, you only see the bottom right adjustment indicator and the chat tab button top-left; and I also hoped that it would not be tied to having 2 alpha sliders.

Remains to be seen what plusmouse has in store for us. Perhaps that mouseover darken could be disabled in another way, or atleast through an optional module.