[00:20] huwshimi: i believe same [00:34] huwshimi: yes, comingsoon is just raw gui which demo is behind apache2 and on prodstack [00:34] huwshimi: one is deployed via the charm and one is via just make devel basically === kadams54-away is now known as kadams54 [01:53] rick_h_, hatch: can either of you reproduce this on anything but chromium? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [02:12] huwshimi: if it's not something you can fix up in a day then backlog it. [02:12] huwshimi: I've not tried to repro to be fair and when it was filed and you had hatch had thuoght about it thought it'd be a quick fix. [02:12] huwshimi: but if it's not something that's common/an issue then I'd suggest we move onto bigger things === kadams54 is now known as kadams54-away [02:25] rick_h_: Well now I've dug into it a bit more I've found that I can only reproduce it in chromium and it doesn't appear to be any of the obvious things that I thought it was, but it's a bit hard to tell some of them when I can't make changes to production :) [02:29] huwshimi: ok [02:29] rick_h_: And that's chromium, not even chrome [02:31] huwshimi: rgr [02:33] rick_h_: What I don't understand is why we only hit it in production, I suspect it might be how we serve gui (Apache2), but I'm not sure which bit of config is causing the issue [02:34] huwshimi: ok, we can come back and revisit it when we figure things out better. Still trying to get the dippy mojo spec to run [02:35] :( === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [15:28] rick_h_: hey you make it in yet? [15:28] hatch: yes, how goes? [15:28] good good - I'm thinking that I'll continue on the apiv4 stuff by building branches on branches [15:28] that way they are still easy to review [15:28] but I won't be blocked by the release [15:29] hatch: ok [15:29] (they will just need to land in order) [15:29] I can push them up to PR as well if you like [15:29] hatch: let's do this. Let's get one up for review and hash on it. While that goes on jump to another bug/issue? [15:29] hatch: that export 'null' thing came up in a bug yesterday [15:29] hatch: and something we should look into [15:30] ahh ok sounds good [15:30] kadams54: what are you up to? Did you grab a new card? [15:30] i'm just running the tests locally I'll have it pushed shortly [15:30] kadams54: so we don't overlap work [15:30] hatch: cool [15:30] rick_h_: I'm working on getting juju alpha, setting up a new user in the env, etc. [15:31] I guess I should move that card over, but was unsure since it also had Makyo on it. [15:31] kadams54: ah ok. I figured we'd start those next week and do some maint. clean out the rest of this week if that's ok [15:32] the ecs entries, the changing a service name (/me pulls Makyo's head from it), the export/'null' issue would all be good high priority stuff to get updated [15:35] Got it [15:36] rick_h_: ok it's up as a PR [15:36] I also have some work from yesterday that I just need to get in a card/PR and land - restoring the CSS animations now that service/relation visibility is CSS. [15:36] switching to the null issue [15:36] kadams54: ah ok cool [15:37] kadams54: yea thanks, just catching up so reading the ouija board...I mean kanban board [15:37] lol [15:38] haha sometimes it sure acts like it moves on its own [15:38] I was talking with a family member yesterday who's a paralegal with a large company. [15:38] He was talking about juggling 30-40 smaller tasks + 3-4 large projects and how the large projects tend to languish because he likes the sense of accomplishment of working on things that can actually get done. [15:39] And I was thinking "yeah, we (programmers) actually figured out a way to systematize that approach and use it to break down the larger projects" [15:39] <3 [15:40] though we all know when that project lane gets into our heads as well still [15:40] but a lot better [15:41] there needs to be a 'feel better' mode in the board lol [15:41] which makes it look like there are less cards [15:42] hatch: heh, well I was using the filter the other day [15:42] hatch: and filtering by the type tag, so only gui, or only storefront [15:42] hatch: so turn that onto your project once in a while and the boards a lot lighter [15:43] oh that's cool if we have all the cards done properly :) [15:43] I try to [15:43] if you catch them not let me know [15:43] or update them [15:43] but yea, every card should have some 'class of service' on them by project type [15:43] I wonder if we can make it a required field [15:47] kadams54: this weekend you need to go through and delete some of your remote branches :P [15:47] lol [15:47] Why? [15:47] 30 is too many! [15:47] I had to remove your remote because it was wrecking my autocomplete [15:47] lol [15:48] uiteam: https://github.com/juju/juju-gui/pull/663 for reviews and QA [15:49] hatch, rick_h_: So 663 restores animations, but TBH I don't like them. [15:49] kadams54: hah, blame luca__ [15:49] The relations and services transition at slightly different times [15:50] kadams54: hmm ok. We'll let's review and get it up on comingsoon and then send an email to peeps and poke luca__ for feedback [15:50] I think to do transitions right would require some pretty complex code and the bang/questionable usability just isn't worth the improvement. [15:50] and make sure if we don't like it we revert before next release [15:50] kadams54: agreed, having not tried it [15:50] kadams54: maybe create a follow up card for it so we make sure to check it out and see what feedback we can get [15:51] rick_h_: sounds like a good idea to keep visibility of it. [15:51] visibility on it [15:51] thanks i'll look at it [15:52] kadams54: AS is broken now lol [15:52] highlight no longer works [15:53] wait nm, [15:53] bad cache [15:53] :P [15:53] Um… yeah. [15:53] uiteam call in 8 kanban please [15:53] Works For Me (TM) [15:53] ;-) [15:54] kadams54: I think you missed the styles on the service icons [15:54] I only see 3 here and they are in the relation class [15:54] Oops, you are likely right. [15:54] :) [15:54] Which would make the timing issue even worse ;-) [15:55] lol right [15:57] Transitions added to services. [15:57] I recall some kind of changelog or history on charm pages? Where is it? https://jujucharms.com/mongodb/trusty/8 [16:00] kadams54: One small issue before I'll +1 [16:17] hatch: Unclear what you mean by "hiding" in your comments - do you mean you're clicking on the eyeball icon? [16:17] kadams54: so when you highlight a service the others which get hidden don't appear to fade out [16:17] but they do fade back in [16:18] Ah [16:18] do you see that too? [16:19] Yes, though I'm not sure why. [16:19] my guess is that some d3 thing is setting a style [16:19] but that's just a twag [16:20] I think it's more to do with display: none [16:21] So we apply two different styles to make it completely hidden: opacity 0, display none. [16:21] opacity transitions, display does not. If the browser chooses to apply the display property before opacity finishes transitioning, you get what we see. [16:22] Unfortunately display is not animatable. You can't specify a transition for it. [16:23] I'm checking to see if there's a workaround [16:23] ahh [16:23] that makes sense [16:23] kadams54: why do we need display none? So that we can't interact with it probably? [16:23] Yeah. [16:24] Otherwise it's still there, gobbling up events. [16:24] the only way I know is with js - maybe we can add pointer events none? [16:24] or something along those lines [16:24] You'd could in theory drag the invisible service block around. Clicking on it would open the inspector. So on and so forth. [16:25] right but with pointer events none it shouldn't do anything [16:26] essentially acting as if it was display none [16:27] kadams54: maybe we set its height and width to 0s? [16:27] just throwing out ideas [16:27] haha [16:28] I suppose that would have the same issue as display none [16:28] Yeah, I actually just tried that. Doesn't work because we'd have to repeat height/width 0 for all contained elements. [16:28] did pointer events work? [16:29] Just setting it for the container doesn't work because the icons and whatnot inside still have height/width [16:29] Yeah, I think pointer-events might work [16:32] So the bad thing about pointer-events is that it only works in IE 11 [16:32] What's our supported browser grid :-) ? [16:33] IE10 because we know we don't work in 11 yret [16:33] there was a long standing maint card to move to IE11 but we didn't get to it [16:33] you can emulate it in i [16:33] e [16:33] one sec [16:33] Sorry, just realized that could be taken multiple ways… the only IE version that supports pointer-events is 11. [16:33] All the rest of the browsers (except Opera Mini) have good support [16:34] I think this works in IE [16:34] filter:alpha(opacity=0); [16:34] http://fromanegg.com/post/47412363539/transparent-links-not-clickable-in-internet-explorer [16:34] I wrote about this a while ago [16:35] They're already transparent due to opacity: 0 [16:35] Is the filter really necessary? [16:35] I don't know - I wrote this forever ago lol [16:35] *sigh* [16:35] fire up an ie vm :) [16:35] I have a feeling I'm going to have to fire up a VM [16:36] Normally I'd say "great minds" but not sure I want to apply that to this case [16:36] haha [16:36] you should pick up parallels you'd have had IE up by now :) [16:37] https://github.com/kmewhort/pointer_events_polyfill/blob/master/pointer_events_polyfill.js [16:37] unfortunately it uses jquery [16:38] ahh here we go [16:38] http://blogs.msdn.com/b/eternalcoding/archive/2013/01/16/hand-js-a-polyfill-for-supporting-pointer-events-on-every-browser.aspx [16:38] says it's supported in IE10 [16:38] kadams54: ^ [16:38] you sure it requires IE11? [16:58] kadams54_: lemme know if you need any help with qa - I have a few IE vm's with various versions of IE === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ [17:19] rick_h_: kadams54_ did you need something from me about animations? [17:20] luca__: Yeah… how badly do you want them? :-) [17:20] kadams54_: which animations are we specifically talking about? [17:20] oh he is just being melodramatic [17:20] :P [17:21] The fading that happens when a service block is faded/hidden/shown on the canvas? [17:21] Hmm, that was not a question. Stupid muscle memory. [17:21] haha [17:23] kadams54_: I would like those animations [17:23] One of the issues is that we can't guarantee that the service block and its relation lines will transition at the same time. [17:25] kadams54_: when I was qa'ing they were identical [17:25] are they not on your machine? [17:25] I've seen some stutter under heavy load [17:25] yeah? [17:25] smooth as butta here [17:25] There's nothing that ensures they'll happen at the same time - we're really just counting on everything happening so fast that it appears to be one giant fade. [17:26] how do you make it under load? [17:27] Run a VM :-) [17:28] I am always in a vm [17:29] I could try and load it up by running boinc or something I guess [17:29] but yeah you're right there is the possibility that they could get out of sync [17:29] not sure how likely that is though [17:30] nothing we can do about the fading stutter if it's under load - I'd imagine then the user would be used to that type of experience :) [17:30] as long as it's not our app causing the load [17:31] kadams54_: I actually wonder if there is any way we could guarantee the fade at the same time - I think the only way would be to wrap the elements in the same container then fade the container [17:31] which isn't going to happen :) [17:31] We could change the implementation to ensure that the class is set on the relations and service at the same time, or at least as close as possible. [17:33] well doesn't that happen now? [17:33] well I suppose one or the other will happen first [17:34] yeah that architecture change also isn't going to happen haha [17:34] that would still only get us closer to correct - it's still possible that they would stutter during the animation [17:36] TBH, I don't really know. It happens in very different sections of code: topology/service.js and topology/relation.js [17:36] I'm guessing both are triggered by the show/fade/hide events [17:36] yeah I can explain it sometime [17:37] but essentially those modules are mixed into the topology master class [17:37] So you could move things around so the class gets set on both the relations and the service element in the same portion of code. [17:37] then update methods are called in sequence [17:37] it's done that way because how d3 works on elements and datasets [17:37] essentially each dataset which corresponds to a ui element is in a new module [17:39] it makes it much easier to reason about once you see how it works. But if I were to redo this (this was done before I started) I would probably do it via some virtual dom like react [17:39] but that's essentially how d3 works for the smaller sections [17:48] uiteam does anyone know what will happen if a config value is "" but the GUI sets the config to null? Will juju-core set it to null or keep it as empty string? [17:50] hatch: honestly, let's bring up a real env and start testing combos? [17:50] hatch: maybe look at a series of 'app.db.services.item(0).... set the config to '', null, undefined, etc and see what juju says in each case [17:51] yeah that sounds like a plan [17:52] the level of fix required is highly dependent on the answer of that question haha [17:52] ty, know it's a pita but I think it's the only way to get a good fix in [17:52] and it'll help QA a lot === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ [18:44] uiteam: the LESS mixin for dealing with CSS3 transition browser prefixes is broken. Browser support for the prefix-less version seems solid (you have to go back four versions on Safari and a couple for Android Browser). Any objections to me dropping browser prefixes and just using it straight up? [18:44] kadams54_: not here no [18:45] I think browsers have dropped them by now [18:45] at least the ones we support have [18:49] Yeah, I verified at caniuse.com [18:53] kadams54_: were you able to come up with a solution to the display: none issue? [18:54] Yes [18:54] I use visibility, which is animatable [18:54] And then I put the transition on a delay so it happens after the opacity finishes. [18:55] ahh nice [18:55] and visibility makes the events not trigger? [18:55] Yes [18:55] I did not know that.. I thought it was the opposite [18:56] Visibility: hidden means the element still takes up space in the document flow [18:56] But it will not respond to mouse events [18:58] nice [18:58] til [19:05] hatch: pushed my fix - give it a whirl and let me know [19:05] will do [19:05] thx [19:25] kadams54_: +1 [19:31] Suh-weet [19:35] uiteam: I need a second +1 on https://github.com/juju/juju-gui/pull/663 [19:37] +1 [19:38] +2 === kadams54_ is now known as kadams54-away === kadams54-away is now known as kadams54_ === kadams54_ is now known as kadams54-away [20:48] apparently I've had a 5 machine juju env running in the background on my laptop this week and I didn't notice [20:51] lxc or kvm? [20:53] lxc's [20:53] but that was within another parallels vm [20:53] vmception [22:07] Morning [22:09] hey huwshimi