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