| 00:22.41 | *** join/#wowuidev purl (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:22.41 | *** topic/#wowuidev is 8.3 ToC: 80300 || 1.13 ToC: 11303 || http://pastebin.com || Discord: https://discord.gg/sVQCHr5 || Battletags: http://bit.ly/2MAEFxk || This channel is logged, via purl |
| 00:25.48 | foxlit | however, you still leak frame positions by not clearing the GetRect returns after ClearAllPoints |
| 00:28.04 | foxlit | so e.g. /run f=CreateFrame("Frame") f:SetAllPoints(NamePlate1) C_Timer.After(0, function() f:ClearAllPoints() print(f:GetRect()) end) |
| 00:28.05 | tacitAndroid | sorry, got pulled into another conversation, reading what you wrote |
| 00:28.42 | tacitAndroid | oh, thanks for that insight, that was definitely unintentional |
| 00:29.31 | foxlit | (possibly the same problem if :StartMoving works after :ClearAllPoints) |
| 00:30.25 | foxlit | in general, I don't think this would work even if implemented perfectly -- you only seem to shield frame positions and anchors from insecure code, and framexml is very, very large. |
| 00:32.35 | foxlit | RE is around and could just ask the non-forbidden nameplates where they are; and even if that doesn't exist, surely something else could be manipulated into calling GetSomethingInconvinient. |
| 00:33.34 | tacitAndroid | in theory RE has been fixed up to prevent friendly nameplate measurement |
| 00:34.01 | foxlit | I think that's about *forbidden* nameplates |
| 00:34.13 | foxlit | not the fancy anchoring-restricted stuff. |
| 00:34.52 | tacitAndroid | the anchor family assignments could be revisited...I would have to go look at some code to remember why I designated WorldFrame as an anchor parent. |
| 00:35.00 | foxlit | (point being that if you relax the forbidden nameplates in instances to only use the anchor-protection, I could probably use RE to figure out where they are) |
| 00:36.24 | tacitAndroid | I think the reason was that I didn't want users to be able to anchor from the nameplate to the center of the screen, so I made explicit families for UIParent/WorldFrame |
| 00:37.02 | foxlit | isn't the screen itself a family? |
| 00:38.18 | foxlit | (so if the nameplates are each in a distinct family, you shouldn't be able to connect them to the screen, or to anything anchored to the screen, like WorldFrame/UIParent, even if WorldFrame/UIParent aren't special) |
| 00:39.09 | tacitAndroid | screen? You mean SimpleTop? |
| 00:39.33 | foxlit | I don't know what you call things internally. I mean whatever you actually anchor to if I call :SetPoint("TOPLEFT", nil, "TOPLEFT") |
| 00:40.19 | tacitAndroid | when the parent of that frame you're invoking SetPoint on is also nil? |
| 00:40.39 | tacitAndroid | e.g. f:SetPoint("TOPLEFT") when f:GetParent() == nil |
| 00:40.46 | foxlit | yes, that too. |
| 00:42.12 | foxlit | (the triple-argument syntax doesn't require the parent to be nil to anchor to nil -- GetPoint would return "TOPLEFT", nil, "TOPLEFT", 0, 0 rather than "TOPLEFT", self:GetParent(), "TOPLEFT", 0,0) |
| 00:42.38 | tacitAndroid | ah, yeah, that ends up being the same behavior...when relativeTo isn't specified SimpleTop/screen is used |
| 00:43.34 | tacitAndroid | so yes, screen is its own family |
| 00:44.12 | foxlit | that makes me think that if UIParent/WorldFrame are not special, they'd be in screen's family because they're anchored to it. |
| 00:45.30 | foxlit | and anchoring something to both a nameplate and the center of UIParent/WorldParent/screen would fail. |
| 00:45.41 | foxlit | s/WorldParent/WorldFrame/ |
| 00:49.20 | *** join/#wowuidev Andols (~yaaic@m83-187-178-49.cust.tele2.se) |
| 00:50.43 | foxlit | => explicitly separating them doesn't seem to serve a purpose. |
| 00:53.32 | tacitAndroid | you raise an excellent point, I'll look into whether or not that will work out. Also, just double checked the default behavior of calling f:SetPoint(...) with a nil relativeTo, and the code has some strange behavior where it starts out by defaulting to f:GetParent(), but then just decides to anchor to screen if relativeTo is nil. Strangely you could force it to anchor to parent by passing in something other than string/table/nil to SetPoint |
| 00:54.30 | tacitAndroid | so, since I missed the initial conversation, what was the actual issue you were having with UIParent/WorldFrame/screen having their own anchor families? |
| 00:55.46 | foxlit | I couldn't explain why it works the way it does. |
| 00:58.22 | foxlit | no actual code-related issue on my side at the moment. |
| 00:58.57 | foxlit | People were observing "strange" things happening with StartMoving in a previous patch (where it'd fail halfway through reanchoring because of the screen/uiparent connection, and in the process trash a number of connected widgets' rectangles, causing fontstrings and textures to disappear). I think you might have fixed that by adjusting StartMoving, but I didn't keep track of the repro steps. |
| 01:01.40 | tacitAndroid | Gotcha, thanks for the heads up, I'll look into seeing if those anchor families can be a little less draconian |
| 01:03.48 | foxlit | Thanks :) |
| 01:53.54 | *** join/#wowuidev Seerah (~umsin@75-36-111-192.lightspeed.mmphtn.sbcglobal.net) |
| 01:53.54 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 02:37.09 | *** join/#wowuidev Shooter (~pi@83.24.137.193.ipv4.supernova.orange.pl) |
| 03:20.10 | *** join/#wowuidev Fisker (~Fisker-@185.109.91.253) |
| 03:48.49 | *** join/#wowuidev Funkeh` (~Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 04:30.54 | *** join/#wowuidev Andols (~yaaic@m83-187-178-49.cust.tele2.se) |
| 04:32.32 | *** part/#wowuidev Seerah (~umsin@75-36-111-192.lightspeed.mmphtn.sbcglobal.net) |
| 04:48.39 | *** join/#wowuidev A-KO (~ako@136.52.64.157) |
| 05:54.36 | *** join/#wowuidev greedom (~greedom@2001:16b8:2eca:4200:cb46:15a6:324b:8c05) |