| 00:09.07 | *** join/#wowuidev Funkeh`` (~Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 00:11.35 | *** join/#wowuidev LexSfX (LexSfX@216-71-194-85.dyn.novuscom.net) |
| 00:14.20 | *** join/#wowuidev LexSfX (LexSfX@216-71-194-85.dyn.novuscom.net) |
| 00:20.23 | *** join/#wowuidev purl (ibot@rikers.org) |
| 00:20.23 | *** topic/#wowuidev is 7.3.x ToC: 70300 || http://pastebin.com || Battletags: http://goo.gl/2bm7n || This channel is logged, via purl |
| 00:27.46 | *** join/#wowuidev Seerah (~umsin@2601:3c2:80:1380:64f9:56d6:4219:6d7f) |
| 00:27.46 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 02:40.32 | Iriel | @Fisker 8-( I did something similar to my Nexus 5, but the pixels since have survied, so far. |
| 02:41.35 | Fisker | I'm trying to see if someone can change the display |
| 02:41.44 | Fisker | I'm holding out for pixel 3 maybe |
| 02:42.07 | Fisker | Hey Seerah |
| 02:42.33 | Fisker | Though because of my new job I might no longer go pixel :( |
| 02:43.10 | Fisker | They only want to go Samsung |
| 03:00.20 | *** part/#wowuidev Seerah (~umsin@2601:3c2:80:1380:64f9:56d6:4219:6d7f) |
| 03:59.51 | *** join/#wowuidev TheDon1 (~TheDon@203-219-137-117.static.tpgi.com.au) |
| 05:08.05 | *** join/#wowuidev ShadniX (dagger@p4FF9FD2D.dip0.t-ipconnect.de) |
| 06:08.12 | *** join/#wowuidev Gethe (~Gethe@cpe-70-112-184-154.austin.res.rr.com) |
| 06:11.55 | *** join/#wowuidev Gethe (~Gethe@cpe-70-112-184-154.austin.res.rr.com) |
| 06:22.03 | *** join/#wowuidev AndChat|96921 (~lonkoenig@c-73-37-220-196.hsd1.mn.comcast.net) |
| 07:10.44 | *** join/#wowuidev VIad (~Vlad@cm-84.213.146.58.getinternet.no) |
| 07:30.13 | *** join/#wowuidev A-KO (~sa@136.52.16.117) |
| 08:17.09 | *** join/#wowuidev Simca (~Simca@c-73-55-2-30.hsd1.fl.comcast.net) |
| 09:20.50 | *** join/#wowuidev LexSfX (LexSfX@216-71-194-85.dyn.novuscom.net) |
| 09:32.52 | *** join/#wowuidev Fisker (~ballmer@a.z.vechs.butts.adultcatfinder.de) |
| 09:50.15 | *** join/#wowuidev Varyak (~Varyak@host-188-174-235-114.customer.m-online.net) |
| 10:01.40 | *** join/#wowuidev dobson (~dobson@68.ip-149-56-14.net) |
| 10:33.29 | *** join/#wowuidev Pursche01 (uid28470@gateway/web/irccloud.com/x-rqiadciappdmvyyz) |
| 10:38.15 | Simca | foxlit: https://wowdev.wiki/DB2#WDC2 just documented this fwiw |
| 10:49.51 | nevcairiel | they bumped the format again? |
| 10:49.55 | nevcairiel | poor foxlit |
| 11:18.15 | VIad | "sections shuffled around randomly for no apparent season" |
| 11:20.27 | nevcairiel | that doesnt mean there is no reason, just that he couldnt figure it out =p |
| 11:42.01 | Chipzz | TheDanW: is there a technical reason other than "it usually doesn't make a lot of sense to call methods on Font objects anyway" that the mixin attribute is not allowed on Fonts? mixins look like sth that could be implemented on a UIObject level... Also, would moving the intrinsic attribute to Region or even UIObject make sense? there are a number of FontString mixins that may or may not make sense as an i |
| 11:42.07 | Chipzz | ntrinsic |
| 11:46.11 | Chipzz | come to think of it intrinsics allow scripts to be overridden and Region is not a ScriptObject descendant, so hmmm... |
| 11:55.29 | VIad | chipzz just ask dan to inv you to the wow github repo and make a patch to fix the issue |
| 11:55.46 | VIad | ezpz lemon squeezy |
| 11:57.01 | Chipzz | VIad: o.O |
| 11:57.49 | Chipzz | VIad: I wasn't even suggesting it was an issue in the first place. Merely asking for the reasoning |
| 11:58.22 | VIad | I think some things are just not for us mortals to understand |
| 12:00.14 | Chipzz | maybe you should let him wake up first before deciding the question has gone ignored and it will remain a mystery forever? |
| 12:06.30 | VIad | I am just joking mate, relax |
| 12:19.09 | *** join/#wowuidev hckhjvw (~yswqqeg@2400:6180:0:d0::aab:c001) |
| 13:18.24 | *** join/#wowuidev ikcerog (~ikcerog@12.165.188.175) |
| 13:33.34 | *** join/#wowuidev pompy (~Mike@c-73-194-183-217.hsd1.nj.comcast.net) |
| 14:56.18 | *** join/#wowuidev tunekey (~tunekey@unaffiliated/tunekey) |
| 15:52.52 | *** join/#wowuidev AcidWeb3 (~AcidWeb@londe.iosphe.re) |
| 15:53.19 | *** join/#wowuidev [TOM_RUS]|2 (~kvirc@95-29-199-38.broadband.corbina.ru) |
| 15:54.14 | *** join/#wowuidev leothar_ (~leothar@84.217.172.58) |
| 15:55.36 | *** join/#wowuidev Kraps_ (sid39333@gateway/web/irccloud.com/x-gfbaorthsyjlycrh) |
| 15:58.05 | *** join/#wowuidev mserrano_ (~mserrano@euler.derig.org) |
| 16:00.56 | *** join/#wowuidev nimhfree_ (~scott@99-117-102-71.lightspeed.sntcca.sbcglobal.net) |
| 16:01.31 | *** join/#wowuidev Sharparam_ (~Sharparam@do.sharparam.com) |
| 16:02.12 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 16:08.17 | *** join/#wowuidev ShadniX (dagger@p4FF9FD2D.dip0.t-ipconnect.de) |
| 16:10.06 | *** join/#wowuidev LexSfX (LexSfX@216-71-194-85.dyn.novuscom.net) |
| 16:10.21 | *** join/#wowuidev Flamegoat (sid89996@gateway/web/irccloud.com/x-flcvogwgzrgofkyy) |
| 16:18.59 | *** join/#wowuidev Buju (~lexlexlex@216.81.62.254.epikip.net) |
| 16:35.42 | *** join/#wowuidev LexSfX (LexSfX@216-71-194-85.dyn.novuscom.net) |
| 17:00.18 | Simca | nevcairiel: you were right. there was a point to the reshuffling that i was missing. |
| 17:00.34 | Simca | it's awful, but there was a purpose |
| 17:37.26 | Chipzz | Simca: care to enlighten us too? :) |
| 17:39.12 | Simca | i'm editing wiki page atm, but tl;dr is WDC2 introduces a new system of 'sections' of data. Three chunks of the structure ('field_storage_info', 'pallet_data', and 'common_data') were moved up in front of the records / 'sections'. Everything after that was broken into a new form of 'sections' which can potentially occur many times in one file. |
| 17:39.26 | Simca | (i copypasted that from the wiki page i'm editing because lazy) |
| 17:40.06 | Chipzz | sure, I also didn't recheck wiki page because lazy :) |
| 17:53.34 | *** join/#wowuidev purl (ibot@rikers.org) |
| 17:53.34 | *** topic/#wowuidev is 7.3.x ToC: 70300 || http://pastebin.com || Battletags: http://goo.gl/2bm7n || This channel is logged, via purl |
| 17:54.34 | Chipzz | TheDanW: also I noticed Animation and AnimationGroup have parentKey attributes but not parentArray (tested it in-game, doesn't work); another oversight? :) |
| 17:55.31 | Funkeh` | TheDanW: wasn't script too long supposed to break large loops in combat? |
| 17:55.52 | Chipzz | ironically, for my own code, disallowing mixin on Fonts actually makes my code more complicated :) so it's easier to be lazy and just allow it by default |
| 17:56.38 | Chipzz | same deal for parentArray |
| 17:57.55 | *** join/#wowuidev ikcerog (~ikcerog@12.165.188.169) |
| 18:04.10 | *** join/#wowuidev Seerah (~umsin@2601:3c2:80:1380:64f9:56d6:4219:6d7f) |
| 18:04.10 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 18:05.49 | Stanzilla | just stop using xml |
| 18:07.17 | TheDanW | both inherits and intrinsics have their usages, i'd generally advocate inherits unless you need to enforce script handler ordering/inheritance |
| 18:09.16 | Chipzz | Stanzilla: contrary to most people here I don't dislike the XML, but well, opinions |
| 18:19.36 | *** join/#wowuidev Tentacled (~Sinus@bck126.neoplus.adsl.tpnet.pl) |
| 18:19.53 | TheDanW | Funkeh`: i reduced/eliminated false positives, you shouldn't need to protect against it |
| 18:20.14 | TheDanW | unless you're doing something bad |
| 18:20.23 | Funkeh` | my concern is the opposite |
| 18:20.23 | TheDanW | then i can't help you with that ;p |
| 18:20.36 | Funkeh` | if I'm doing something bad it's not protecting me |
| 18:20.50 | foxlit | the public demands an exhaustive list of all the bad things ;) |
| 18:21.26 | TheDanW | it's not intended to protect you |
| 18:22.50 | Tentacled | Hmm. Core FrameXML question. I have some clickable controls in a scrollchild/frame, and I noticed that they're still clickable even when they scroll out of the viewport. Is that normal, or something I broke..? |
| 18:22.56 | Funkeh` | so it's ok for an addon to crash the game? |
| 18:24.03 | Chipzz | Funkeh`: depends who/what you mean by "You" I guess |
| 18:24.20 | Chipzz | if "You" means "the addon", then no it's not meant to protect "you" |
| 18:24.39 | foxlit | Tentacled: something blizzard broke; there's some other property that forces it back to the old behavior you expect |
| 18:24.42 | Funkeh` | that doesn't even make sense |
| 18:24.46 | Chipzz | if "You" means the user sitting behind the PC might be a different thing |
| 18:25.19 | Chipzz | then nevermind what I said :P |
| 18:36.04 | Tentacled | Hmm. None of the default FrameXML-and-family files use any odd-looking attributes or properties on scrollframes/scrollchildren :/ |
| 18:36.11 | *** join/#wowuidev Semlar (~semlar@72.189.128.149) |
| 18:38.57 | foxlit | and do they also all suffer from the clickable-clipped-child syndrome? |
| 18:39.37 | Tentacled | Ah wait, clipChildren="true"? |
| 18:40.08 | foxlit | probably. |
| 18:40.40 | foxlit | then again there's also http://www.wowinterface.com/forums/showpost.php?p=326605&postcount=5 |
| 18:49.03 | *** join/#wowuidev Justwait (~Justwait@546B1128.cm-12-4a.dynamic.ziggo.nl) |
| 18:49.14 | Tentacled | Hmm. Interesting. Thanks. |
| 18:52.06 | TheDanW | there's some confusion in that thread, i can't tell if there's actually a bug, if there is and you have a repro i'll check it out |
| 18:52.49 | Chipzz | that thread is 2 year old anyway |
| 18:53.17 | *** join/#wowuidev Resike (~Resike@62.77.234.203) |
| 18:53.45 | TheDanW | toplevel seems misunderstood, it does two things, it effectively enables render flattening (this can also be enabled by being a scroll child, enabling child clipping or explicitly with SetFlattensRenderLayers), secondly it enables the behavior of increasing the frame level when it is clicked, bring it to the top |
| 18:54.30 | Chipzz | does it affect output only or input too? |
| 18:54.54 | Resike | why is child clipping is not enabled by deafult for scrollframes? |
| 18:55.03 | TheDanW | Chipzz: how do you mean? |
| 18:55.32 | TheDanW | Resike: that's what scroll child does, everything should be parented to it either directly or indirectly to be clipped, scroll frames themselves do not clip |
| 18:55.42 | Chipzz | maybe I should test myself first before asking |
| 18:56.11 | Chipzz | but what I meant: output -> rendering; input -> mouse events; are these 2 always handled together? |
| 18:56.33 | TheDanW | well sort of, frames don't render anything |
| 18:57.19 | Chipzz | would make sense if they're always handled together, but maybe there are bugs/edge cases where one is forgotten? |
| 18:58.25 | TheDanW | child frames of clipped frames (either by being a scroll child or by SetClipsChildren) should not be clickable |
| 18:58.42 | TheDanW | but anchoring a frame to a clipped frame won't clip it |
| 18:58.57 | TheDanW | i'm not aware of any bugs with it currently |
| 19:01.45 | Resike | im confused but i did not managed to create a proper scrolling frame without SetClipsChildren(true) |
| 19:03.04 | Resike | doesn't SetScrollChild(frame) parents the frame to the scrollframe by default? |
| 19:04.56 | TheDanW | yeah |
| 19:07.00 | Chipzz | Tentacled: not that it matters much to you, but this conversation is quite interesting to me because my emulator has bugs in the exact same area :) |
| 19:07.10 | Chipzz | well, bugs, more like NYI :P |
| 19:07.19 | foxlit | Meh, works for me without any special hoops |
| 19:08.09 | foxlit | The closest thing to weirdness randomly poking around the default UI is that the equipment set list scrollframe in the character info panel highlights the set buttons even if you're mousing over the clipped portion of the button. |
| 19:08.38 | foxlit | doesn't actually handle clicks, so whatever. |
| 19:10.11 | Tentacled | Chipzz, I'm all the more glad to have thrown this tiny spark onto the collective straw pile ;) |
| 19:13.51 | Chipzz | Tentacled: http://chipzz.safehex.be/clipping.png :P |
| 19:15.25 | Tentacled | Something fell off from your window sill ;P |
| 19:16.38 | Chipzz | yeah, that's the highlight for one of the buttons |
| 19:43.59 | *** join/#wowuidev Itwillbeapps (187a511f@gateway/web/freenode/ip.24.122.81.31) |
| 19:54.50 | Simca | https://wowdev.wiki/DB2#WDC2 updated |
| 20:00.22 | Itwillbeapps | Hey guys, I'm trying to find information about how "on demand" addons work. I can't seem to find what I'm looking for so I'd appreciate if somebody could point me in the right direction. I'm wondering, for example, is it possible for an addon to be loaded when you enter a raid, then unloaded when you leave that raid. What happens to global variables created by said addon when it is unloaded? Does the game client keep track of w |
| 20:01.10 | TheDanW | there's presently no way to unload an addon, short of reloading the UI |
| 20:04.56 | Itwillbeapps | Thanks, that's interesting! So, if I have a modules based addon with a core and a few modules, and the core has a global table, is there any downside to adding modules functions and variables to that table? I was worried about them not being cleaned up when a module is unloaded, but if they can't be unloaded, that doesn't seem like a problem. |
| 20:15.58 | Chipzz | Itwillbeapps: I think I may have a relevant url lying around, let me look; also, Frames and other objects also can not be unloaded |
| 20:18.32 | Chipzz | hmmmm wasn't as relevant as I thought (and hardly any info anyway); addon load managers: http://www.wowinterface.com/forums/archive/index.php/t-9417.html |
| 20:19.59 | Chipzz | Itwillbeapps: I doubt there will ever be a way to unload addons; addons can basically do anything, including fucking around (like hooking) other addons or even the core UI (hooksecurefunc) |
| 20:20.26 | Chipzz | it would be extremely hard to a) keep track of everything an addon does and b) undo it too |
| 20:21.11 | Itwillbeapps | Yeah, that explains why I couldn't wrap my head around it. It makes sense now! Thank you |
| 20:21.52 | Chipzz | even if you could keep track, what would you undo to? the state it was in before the addon loaded? but what if another addon made other changes? |
| 20:24.05 | Itwillbeapps | It felt odd because I assume the point of "Load on demand" is to not "waste" memory until you actually need the addon, so I assumed there was some way to reclaim memory once an addon is no longer needed, but like you said, it would be very difficult to pull off. Makes me think that a small addon might as well always be loaded |
| 20:24.24 | Itwillbeapps | all the time |
| 20:46.19 | *** join/#wowuidev pompy (~Mike@c-73-194-183-217.hsd1.nj.comcast.net) |
| 20:47.28 | *** join/#wowuidev pompy (~Mike@c-73-194-183-217.hsd1.nj.comcast.net) |
| 20:55.27 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 21:55.52 | *** join/#wowuidev pompy1 (~Mike@c-73-194-183-217.hsd1.nj.comcast.net) |
| 22:15.58 | *** join/#wowuidev purl (ibot@rikers.org) |
| 22:15.58 | *** topic/#wowuidev is 7.3.x ToC: 70300 || http://pastebin.com || Battletags: http://goo.gl/2bm7n || This channel is logged, via purl |
| 22:46.30 | Mr_Rabies | dbm uses it, for example, to mostly only load the modules for whatever raid you're in |
| 23:04.58 | Simca | in general there isn't a large point though, especially for tiny addons |
| 23:07.19 | Mr_Rabies | yeah unless you got some insane modular thing like dbm with a ton of modules that are generally optional |
