hatch | huwshimi: i believe same | 00:20 |
---|---|---|
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 | 00:34 |
=== kadams54-away is now known as kadams54 | ||
huwshimi | rick_h_, hatch: can either of you reproduce this on anything but chromium? | 01:53 |
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
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:12 |
=== kadams54 is now known as kadams54-away | ||
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:25 |
rick_h_ | huwshimi: ok | 02:29 |
huwshimi | rick_h_: And that's chromium, not even chrome | 02:29 |
rick_h_ | huwshimi: rgr | 02:31 |
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:33 |
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:34 |
huwshimi | :( | 02:35 |
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54 is now known as kadams54-away | ||
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
kadams54 | Got it | 15:35 |
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:36 |
rick_h_ | kadams54: yea thanks, just catching up so reading the ouija board...I mean kanban board | 15:37 |
kadams54 | lol | 15:37 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:47 |
kadams54 | uiteam: https://github.com/juju/juju-gui/pull/663 for reviews and QA | 15:48 |
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:49 |
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:50 |
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:51 |
hatch | kadams54: AS is broken now lol | 15:52 |
hatch | highlight no longer works | 15:52 |
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:53 |
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:54 |
hatch | lol right | 15:55 |
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 | 15:57 |
hatch | kadams54: One small issue before I'll +1 | 16:00 |
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:17 |
kadams54 | Ah | 16:18 |
hatch | do you see that too? | 16:18 |
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:19 |
kadams54 | I think it's more to do with display: none | 16:20 |
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:21 |
kadams54 | Unfortunately display is not animatable. You can't specify a transition for it. | 16:22 |
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:23 |
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:24 |
hatch | right but with pointer events none it shouldn't do anything | 16:25 |
hatch | essentially acting as if it was display none | 16:26 |
hatch | kadams54: maybe we set its height and width to 0s? | 16:27 |
hatch | just throwing out ideas | 16:27 |
hatch | haha | 16:27 |
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:28 |
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:29 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
hatch | https://github.com/kmewhort/pointer_events_polyfill/blob/master/pointer_events_polyfill.js | 16:37 |
hatch | unfortunately it uses jquery | 16:37 |
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:38 |
hatch | kadams54_: lemme know if you need any help with qa - I have a few IE vm's with various versions of IE | 16:58 |
=== kadams54_ is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54_ | ||
luca__ | rick_h_: kadams54_ did you need something from me about animations? | 17:19 |
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:20 |
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:21 |
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:23 |
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:25 |
hatch | how do you make it under load? | 17:26 |
kadams54_ | Run a VM :-) | 17:27 |
hatch | I am always in a vm | 17:28 |
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:29 |
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:30 |
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:31 |
hatch | well doesn't that happen now? | 17:33 |
hatch | well I suppose one or the other will happen first | 17:33 |
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:34 |
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:36 |
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:37 |
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:39 |
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:48 |
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:50 |
hatch | yeah that sounds like a plan | 17:51 |
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 | 17:52 |
=== kadams54_ is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54_ | ||
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:44 |
rick_h_ | I think browsers have dropped them by now | 18:45 |
rick_h_ | at least the ones we support have | 18:45 |
kadams54_ | Yeah, I verified at caniuse.com | 18:49 |
hatch | kadams54_: were you able to come up with a solution to the display: none issue? | 18:53 |
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:54 |
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:55 |
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:56 |
hatch | nice | 18:58 |
hatch | til | 18:58 |
kadams54_ | hatch: pushed my fix - give it a whirl and let me know | 19:05 |
hatch | will do | 19:05 |
hatch | thx | 19:05 |
hatch | kadams54_: +1 | 19:25 |
kadams54_ | Suh-weet | 19:31 |
kadams54_ | uiteam: I need a second +1 on https://github.com/juju/juju-gui/pull/663 | 19:35 |
Makyo | +1 | 19:37 |
hatch | +2 | 19:38 |
=== kadams54_ is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54_ | ||
=== kadams54_ is now known as kadams54-away | ||
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:48 |
jrwren | lxc or kvm? | 20:51 |
hatch | lxc's | 20:53 |
hatch | but that was within another parallels vm | 20:53 |
hatch | vmception | 20:53 |
huwshimi | Morning | 22:07 |
hatch | hey huwshimi | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!