[00:14] <huwshimi> hatch: Here we go: https://github.com/juju/juju-gui/pull/193
[00:41] <hatch> huwshimi looking
[00:41] <hatch> lookin good
[00:41] <hatch> I'll do the review in a bit
[00:42] <hatch> huwshimi the ci failed
[00:43] <huwshimi> hatch: Yeah, was just looking at that. It's as if I didn't get the module-debug.js update...
[00:43] <hatch> you need to add the extension file into merge-files
[00:43] <hatch> bin/merge-files
[00:43] <hatch> you'll see a huge list of them
[00:44] <huwshimi> Ah I see
[00:44] <huwshimi> hatch: I've got another change to make before you can do a full review anyway, so hold off on that.
[00:44] <hatch> yes it's sad that I knew these things
[00:44] <hatch> lol
[00:45] <hatch> yeah no problem
[00:46] <huwshimi> haha
[01:13] <hatch> huwshimi ready for review?
[01:14] <huwshimi> hatch: Not quite, just adding tests for events
[01:14] <hatch> ok np, I may not get to a review for tonight then
[01:15] <huwshimi> hatch: It might be done it two mins...
[01:15] <hatch> oh ok
[01:15] <hatch> well ping me and I'll try and get to it :)
[01:20] <huwshimi> hatch: Just rebase and pushing now.
[01:22] <huwshimi> hatch: Ready! https://github.com/juju/juju-gui/pull/193
[01:22] <hatch> ohhh kay
[01:22] <hatch> on it
[01:23] <huwshimi> Thanks!
[01:44] <huwshimi> hatch: Just going to have lunch so I'll fix up after that.
[01:44] <huwshimi> hatch: Thanks heaps for reviewing
[01:45] <hatch> huwshimi no problem - it's a pretty nit picky review :P
[01:45] <hatch> I'm just doing a qa now
[01:50] <huwshimi> hatch: That's fine, happy to have that kind of review
[01:51] <hatch> cool :) I should do more of them lying on the couch hah
[01:51] <hatch> huwshimi ohh, I'm nto sure if you noticed but we upgraded node while youw ere gone
[01:53] <huwshimi> hatch: Ah right, means we can move to sass right?
[01:53] <hatch> I believe that was the holdup you mentioned - so I'm taking your word on it
[01:53] <hatch> :P
[01:54] <huwshimi> hatch: Nice, thanks!
[01:54] <rick_h_> hatch: thanks for hanging on and reviewing appreciate it
[01:54] <rick_h_> hatch: but don't run too long
[01:54] <rick_h_> thanks for the awesome updates huwshimi, I think this will work out much nicer to build on top of
[01:55] <rick_h_> really nice base
[01:56] <huwshimi> rick_h_: Great!
[01:57] <hatch> party on!
[01:57] <huwshimi> rick_h_: I'm going to fix up this branch and then would you be happy for me to get scss working again?
[01:58] <huwshimi> I guess my next branch to work on is "create machine panel view" which requires the header to have landed.
[01:59] <huwshimi> But, not sure if I can tackle that without an imp call
[02:00] <rick_h_> huwshimi: as much as I <3 scss > less the machine view/inspector stuff is priority
[02:00] <rick_h_> huwshimi: I assigned a small bug your way from luca today or last night if you get a chance to look 
[02:00] <huwshimi> rick_h_: No problems. I'll take a look at the bug.
[02:00] <rick_h_> huwshimi: and then yea, the machine panel view I think would be next to go, it fits in somewhat with what hatch is working on
[02:03] <rick_h_> huwshimi: noticed you had hte wrong card there for your task
[02:03] <rick_h_> swapped those over
[02:04] <rick_h_> huwshimi: so yea, there's two other machine view component cards after this one. 
[02:04] <rick_h_> huwshimi: but please feel free to add a scss conversion to the slack lane and if you get stuck on something sometime it'd be a cool background task
[02:05] <huwshimi> OK sure
[02:05] <rick_h_> night all, sleepy techie...
[02:05] <huwshimi> rick_h_: Night!
[12:27]  * frankban lunches
[12:36] <rick_h_> frankban: thanks for looking into that issue. I'm glad the original assignee has spoken up now
[13:26] <jcastro> rick_h_, rails/example-scalable is missing from the web UI
[13:26] <jcastro> exists in the store afaict
[13:26] <rick_h_> jcastro: k, looking
[13:27] <rick_h_> jcastro: full url?
[13:27] <jcastro> https://code.launchpad.net/~charmers/charms/bundles/rails/bundle
[13:31] <rick_h_> jcastro: added a card to try to get it investigated. I'm out on an intro sprint this week so might be a day/two to get a good look. 
[13:31] <rick_h_> jcastro: nothing obvious wrong, proof's, etc
[13:32] <rick_h_> jcastro: but it loads on staging so it's something with production and the awesome black box there
[13:32] <rick_h_> http://staging.jujucharms.com/bundle/~charmers/rails/example-scalable
[13:33] <jcastro> cool
[13:51] <rick_h_> bwuhahaha http://comingsoon.jujucharms.com/:flags:/il/mv/
[13:51] <rick_h_> starting to look like something
[13:51] <rick_h_> that doesn't do anything at all, but it looks :)
[14:02] <hatch> haha
[14:03] <hatch> with these short names we have to be sure we grep for flags.il 
[14:06] <frankban> and the fiber connection appears to be working (he said)
[14:09] <hatch> OOoooOoo
[14:16] <frankban> rick_h_: 1.17.6 is in trusty. I am starting quickstart QA on it
[14:21] <jcastro> rick_h_, don't forget to remove ~charmers from bundles too!
[14:23] <frankban> ... and it failed
[14:24] <frankban> guihelp trusty users: have you encountered this issue before? http://pastebin.ubuntu.com/7151411/
[14:33] <hatch> I've run into quite a few odd issues with juju-core in the 1.17.x branches - hoping they all get resolved before 1.18 :)
[14:34] <frankban> hatch: yeah, I am trying to figure out if this should block the quickstart release
[14:35] <hatch> it doesn't look like a quickstart bug
[14:35] <hatch> it looks like a core bug
[14:36] <frankban> hatch: precisely
[14:36] <frankban> asked on #juju-dev
[14:39] <hatch> frankban the first thing they will ask is 'is there anything in the logs' so you might as well check there first :)
[14:40] <frankban> hatch: I am checking if this also affects saucy
[14:40] <hatch> early access "Go In Action" http://manning.com/ketelsen/ looks like there are only two chapters available so far
[14:41] <jcastro> rick_h_, does drag and dropping a bundle with multiple stanzas work yet?
[14:41] <jcastro> basically, the design people need to get updated pictures for the juju flyer
[14:41] <hatch> george co....stanza?
[14:42] <hatch> jcastro do you mean stanza wrt multiple bundles in one deployer file?
[14:42] <jcastro> yeah
[14:42] <hatch> if so, no it's not supported yet
[14:42] <jcastro> ugh
[14:42] <jcastro> so basically, the rails bundle is undeployable
[14:43] <hatch> well I thought that the charmstore splits them up?
[14:43] <jcastro> yeah but the design people are likely using the GUI
[14:44] <hatch> I mean - I was under the impression that the charmstore splits them up so the search results should show multiple bundles in the result list
[14:45] <jcastro> oh hey
[14:45] <jcastro> does it work on comingsoon?
[14:46] <hatch> when I search for rails there is a single recommended bundle
[14:46] <jcastro> right, but the 2nd one is missing
[14:46] <hatch> ahh so it only takes the first one
[14:46] <jcastro> rails:example-simple is there, rails:example-scalable is not
[14:47] <hatch> yeah looks like a charmworld feature isn't there
[14:47] <hatch> the gui just shows what it's given
[14:50] <Makyo> jujugui call in 10
[14:51] <hatch> man that call comes up quick now
[14:58] <Makyo> jujugui callin 2
[15:07] <benji> I was just kicked out of the call.  Trying to reconnect.
[15:13] <Makyo> afk a few minutes
[15:16] <hatch__> benji since you switched to this new camera you have been having a lot of video issues
[15:17] <hatch> new and unimproved? :)
[15:17] <benji> hatch: yep (but today's camera was the old one)
[15:17] <hatch> ohh interesting, it seemed to freeze just like the 'new' one
[15:18] <hatch> maybe a trusty driver issue?
[15:19] <rick_h_> jcastro: yes, it's undeployable atm. We won't have multiple dropping support for a while
[15:19] <rick_h_> jcastro: we should be able to start looking at it later today/tomorrow. 
[15:37] <hatch> new HTC One
[15:37] <hatch> ooooo
[15:37]  * hatch looks at mine.....looks at the new one
[15:48] <frankban> jujugui: http://jujugui.wordpress.com/2014/03/25/juju-quickstart-1-2-0-released/
[15:48] <hatch> w00t
[15:48] <frankban> hazmat, marcoceppi: I just updated the juju stable PPA with the backported packages of deployer (0.3.4) and jujuclient (0.17.5)
[15:49] <marcoceppi> \o/
[15:49] <kadams54> Nice
[15:50] <hatch> ahhhh my brain does not work like browser.js
[15:50] <hatch> must....not....rewrite.....routes.....
[15:54] <rick_h_> frankban: woot!
[15:54] <rick_h_> frankban: once it hits pypi can you ping james page and look into getting an updated upload to trusty and talk to him about closing out our FFE bug for it
[15:54] <rick_h_> hatch: :P
[15:55] <rick_h_> hatch: ignore routes, they don't exist 
[15:55] <rick_h_> it's magic :)
[15:55] <frankban> rick_h_: it's already on pypi, pinged rbasak about that
[15:55] <rick_h_> as soon as you touch routes you get hit in the head by double dispatch and life sucks
[15:55] <rick_h_> frankban: ok awesome thanks
[15:55] <frankban> mp
[15:55] <hatch> sounds like we should fix double dispatch :)
[15:56] <rick_h_> hatch: it's already fixed for you as long as you stay away from routes
[15:56] <rick_h_> hatch: mission accomplished, plus we need more state than a url/route can handle so you can't get rid of it anyway
[15:57] <rick_h_> jcastro: that quickstart release removes ~charmers
[15:57] <rick_h_> jcastro: and we've updated the deploy instructions in the gui and should be release later this week 
[15:57] <hatch> I guess I prefer the router to be explicit '/inspector/:service/:unit' for example
[15:57] <rick_h_> that's fine
[15:57] <rick_h_> but don't think route, it's state
[15:58] <hatch> right but the route can call a single method instead of one who's 100 lines long and has way too many responsibilities 
[15:58] <rick_h_> which 100 line method?
[15:58] <rick_h_> *cough* there isn't one *cough*
[15:58] <hatch> sidebar + routeView is over 100 lines
[15:58] <rick_h_> that's two functions :)
[15:58] <hatch> sidebar is only 4 lines shorter than 100 lines
[15:58] <hatch> :)
[15:58] <rick_h_> and I admit that the sidebar function can be broken up into smaller bits
[15:59] <rick_h_> hatch: heh, yea and it's commented to high heaven
[15:59] <rick_h_> shall I go look at other methods in other bits of the code? 100 lines eh?
[15:59] <hatch> I still think that the router should be the source of truth
[15:59] <rick_h_> hatch: and that can't happen
[15:59] <rick_h_> it's not smart enough
[16:00] <hatch> why can't the router call a method which updates the state?
[16:00] <rick_h_> hatch: we can chat about it if you want. I'll tell you where the router falls short for our uses and why state still needs to be there even in a non-double dispatch world
[16:00] <rick_h_> because not every thing we draw is/should/can be in the url
[16:01] <hatch> right but anything touching the router is from the url
[16:01] <rick_h_> what tab is selected in the inspector? How about which tab in the service details popout? 
[16:01] <rick_h_> man, the router isn't official in any other code in the GUI. Why is it NOW a problem? I mean what in the inspector, service view, etc deals with it?
[16:01] <hatch> right, and those can be separate methods which update the state and don't need to touch the router
[16:01] <rick_h_> right, so forget the route and just deal with state. Have one source of truth. 
[16:02] <rick_h_> if you split up into a bunch of routes with state and async renders for those route callbacks it'll be hell 
[16:02] <rick_h_> I've been down that road with the browser
[16:02] <rick_h_> that's even before double dispatch
[16:03] <rick_h_> it's more complex then a todo app :)
[16:03] <hatch> right but right now it's impossible to tell what routes are support or, looking at a url, what is supposed to happen without parsing through many lines of code
[16:03] <rick_h_> ok, I'll give you that's fair. 
[16:04] <hatch> I think a lot of what we are doing can be done with 'middleware' routes and then specific ones with defined methods
[16:04] <rick_h_> the discoverabiity/etc isn't as easy with routes, but it wouldn't be anyway. 
[16:04] <rick_h_> hatch: right, if we rewrite everything, remove double disptach, and get to some ideal state it might be cool and work out better. 
[16:04] <rick_h_> but it's a LONG way from where the world is now
[16:04] <hatch> but I think we can handle double dispatch with middleware
[16:04] <rick_h_> and it's not something we've got the bandwidth to fix between now and vegas
[16:04] <hatch> is what I'm saying
[16:04] <rick_h_> that's what the state does
[16:05] <hatch> exactly
[16:05] <rick_h_> it already deals with double dispatch as a middle layer
[16:05] <rick_h_> so why is it so bad to work with?
[16:05] <hatch> I think that the routes should call specific methods to update the state, then a middleware layer to check if it's the same, if it is, then don't next()
[16:06] <hatch> so then we maintain the state funcitonality
[16:06] <hatch> which we both agree is necessary
[16:06] <hatch> but we have meaningful routes
[16:08] <rick_h_> hatch: maybe, we can talk about it
[16:08] <rick_h_> hatch: I've got to get ready to head out to lunch with ramm
[16:08] <hatch> yeah np I'm implementing it as it is
[16:09] <rick_h_> hatch: I don't mean to be a pita, but it seems that rewriting what's working and is well documented and tested and not a complete mental nightmare seems a bit overkill but maybe I'm too close to it
[16:09] <rick_h_> hatch: we can try to setup some time to look at a proof of concept for reworking it some, but we just spent 2 weeks fixing the inspector to be easier to work with and I don't think we've got the bandwidth to do the same to the browser.js 
[16:09] <hatch> yeah that's fine
[16:10] <hatch> it would probably take us at least a week if not two to rewrite this too
[16:10] <hatch> we definitely can't do it before vegas
[16:11] <kadams54> Alrighty, rick_h_ and I are afk for lunch
[16:24] <hatch> I still have two more keybase.io invites if anyone wants
[16:40] <hatch> good nuf? https://www.evernote.com/shard/s219/sh/9a098cc5-6ee6-4770-928c-b44856f06eca/4b02fa5abc7f79a5c0266ceb527c9639
[16:42] <hatch> Makyo do you know if we could have a url for the ghost inspector?
[16:42] <hatch> I'm trying to figure out the best way to update the state and it seems like a url would be the best
[16:42] <Makyo> hatch, Not sure I think that's a very good idea.
[16:43] <Makyo> It's not a bad one, it's just showing transient local state in the URL (which can be shared)
[16:43] <hatch> so here is the issue...the user drags and drops a charm on the canvas, the drop event comes form the canvas
[16:43] <Makyo> So if you have a ghost inspector open and try to share the URL with someone else, it'll fail.
[16:43] <hatch> it now needs to go up to the browser subapp to render the inspector
[16:44] <Makyo> Mmhm.
[16:44] <hatch> well...it would open a inspector to deploy that charm
[16:44] <Makyo> With no drop position info.
[16:44] <hatch> ahh right
[16:44] <Makyo> Or any changes the user has made to config
[16:44] <hatch> the path from the canvas to the browser sidebar is not a clear one :)
[16:44] <Makyo> Yeah, that's fair :/
[16:44] <Makyo> Events? :D
[16:44]  * Makyo ducks
[16:44] <hatch> could fire an event but that's a long way
[16:44] <hatch> lol
[16:45] <hatch> could pass a method down
[16:45] <hatch> but not sure if that's any better than an event 
[16:45] <hatch> it's like using a really long stick to poke a switch heh
[16:46] <hatch> updating the url could 'just work' but I see what you're saying
[16:46] <hatch> we could include positional information in the url
[16:47] <hatch> but I guess that would be weird back-button functionality 
[16:48] <hatch> we could pop it out of the history heh
[16:48] <hatch> ok I think I know what i'll do
[16:49] <Makyo> Using the URL as an event dispatcher? :P
[16:49] <hatch> lol 
[16:50] <hatch> I'll move the inspector creation code from environment.js into browser.js and then fire an event from the canvas > app > browser
[16:50] <hatch> the event targets should allow that pretty trivially right now
[16:50] <hatch> oh...wait
[16:50] <hatch> there are a bunch of events from the canvas to the inspector
[16:50] <hatch> hmmm
[16:52] <hatch> we need a better transport mechanism
[16:59] <hatch> events it is
[17:13] <hatch> we need a indexdb juju environment so we can test this new inspector stuff without being in a real env
[17:14] <hatch> it's impossible right now to see /inspector/:service work in the simulator 
[17:14] <hatch> I wonder how hard that would be....
[17:14] <hatch> hmmmmm
[17:14] <hatch> probably not horrible
[17:18] <arosales> rick_h_: re the rails bundle error. If trunk is working correctly and you have that running locally can you help us get a screen shot of the rails bundle with all green?
[17:19] <arosales> rick_h_: the need here is to get a design a good screen shot for the flyers going to GopherCon and OSCON
[17:23] <hatch> arosales he is out for lunch atm
[17:23] <hatch> should be back rather soonish
[17:24] <arosales> hatch: thanks for the info.
[17:48] <hatch> heh - showing the service relation menu has been creating inspectors
[17:48] <hatch> stealth bug....
[17:53] <kadams54> back
[17:53] <hatch> squished
[17:53] <hatch> kadams54 good lunch?
[17:54] <kadams54> Yeah. Yelp did not lead us astray.
[17:54] <hatch> I get left overs
[17:54] <kadams54> Chinese leftovers?
[18:00] <rick_h_> arosales: k, yes. We can get a screenshot. Will take a few 
[18:01] <rick_h_> hatch: I don't think that the ghost inspector would be url-able? 
[18:01] <hatch> kadams54 home made stir fry...so sort of asiany
[18:01] <rick_h_> hatch: sorry catching up on log
[18:01] <hatch> rick_h_ yeah I've done some uglyness to get the topology into the browser
[18:01] <hatch> I think it's just something we will have to deal with
[18:01] <rick_h_> hatch: k, these are the pain points for sure. 
[18:01] <hatch> it's all commented up 
[18:02] <rick_h_> hatch: this is where I was expecting the main work in the move to be 
[18:02] <rick_h_> hatch: k
[18:02] <hatch> rick_h_ current wip https://github.com/hatched/juju-gui/compare/prep-charmbrowser?expand=1 
[18:03] <hatch> in case you were curious
[18:03] <rick_h_> hatch: k, looking while I get a gui up for arosales 
[18:03] <arosales> rick_h_: thanks. I also sent a mail with instructions and needs
[18:04] <arosales> jcastro: ^
[18:04] <jcastro> rick_h_, we need one of each bundle, mongodb:cluster and rails:example:scalable
[18:05] <rick_h_> jcastro: ok, but you've got the mongodb cluster right?
[18:05] <jcastro> rails:example-scalable rather
[18:05] <jcastro> not with the new sidebar no
[18:05] <rick_h_> new sidebar?
[18:05] <jcastro> on the left
[18:05] <jcastro> the inspector 
[18:05] <rick_h_> well that doesn't exist yet
[18:05] <rick_h_> that's WIP
[18:05] <jcastro> yeah it's for the flyer so we want it to be as close to the future as possible
[18:06] <rick_h_> jcastro: k
[18:07] <arosales> rick_h_: in the email Spencer had some examples of the sidebar bits
[18:07] <rick_h_> arosales: yes, he's designing stuff but we don't have it implemented. It's what we're doing for 14.05 right now
[18:07] <rick_h_> arosales: do you have this email? I'm not seeing it
[18:08] <rick_h_> arosales: sorry found it
[18:08] <arosales> rick_h_: email subj = "Fwd: Images for flyer"
[18:09] <rick_h_> arosales: yes, there's no pic in there though. I don't know what spencer is sending you
[18:10] <arosales> rick_h_: sent w/ attachment
[18:10] <rick_h_> heh yea see it. Those are pure design mock ups. I can't recreate that with a bundle and such and live data
[18:13] <rick_h_> arosales: jcastro http://uploads.mitechie.com/lp/rails-bundle-screenshot.png chop and use it as you see fit. 
[18:13] <rick_h_> arosales: jcastro since it loads on staging I just deployed the gui into a lxc environment and changed the config for "charmworld-url"  juju set juju-gui charmworld-url="http://staging.jujucharms.com/" 
[18:13] <rick_h_> for reference if you need something like this and I'm afk/etc
[18:14] <hatch> rick_h_ if you zoom out does it show the bottom of the bundle vis?
[18:15] <arosales> rick_h_: ok so jcastro you should be able to do this for mongo with the config settings
[18:15] <hatch> that's one heck of a bundle heh
[18:15] <rick_h_> arosales: we shouldn't need it for mongodb. That one is ingested and working fine
[18:15] <rick_h_> you can do that on comingsoon or jujucharms.com
[18:17] <jcastro> yeah mongodb isn't a problem
[18:17] <jcastro> it's rails that was the problem
[18:18] <arosales> jcastro: but you still need the new sidebar for mongo, which sounds like we can get a comingsoon
[18:18] <rick_h_> arosales: that is not true
[18:19] <arosales> rick_h_: /me just going off what jcastro sayd he has in terms of side bars
[18:29] <marcoceppi> rick_h_: if we delete a branch from launchpad will the charm be removed from charmworld?
[18:29] <rick_h_> marcoceppi: no, but we're getting a removal UI in charmworld to help with this
[18:30] <rick_h_> marcoceppi: it's committed but not deployed yet
[18:30] <rick_h_> marcoceppi: should get a deploy out this week with it
[18:30] <marcoceppi> rick_h_: anything we can do in the mean time?
[18:30] <rick_h_> marcoceppi: what's the details around it?
[18:30]  * hatch stepping out for some lunch errands
[18:30] <hatch> bbiab
[18:42] <jcastro> rick_h_, fixed that cassandra README issue, I'm going to file a bug on charm-tools to check for that
[18:45] <rick_h_> jcastro: k thanks. Sorry to punt on it
[18:46] <jcastro> it's fine, it's a subtle thing that we should be enforcing in policy anyway
[19:06] <hatch> rick_h_ I'm replying to your comments - which one is `il` again? lol (the problem with too short flags)
[19:09] <Makyo> Inspector Left
[19:10] <rick_h_> hatch: ok cool, chat after you go through them?
[19:10] <hatch> ohh
[19:10] <hatch> ok then yes
[19:10] <hatch> :)
[19:10] <rick_h_> hatch: sorry, pm'd you in invisible space :)
[19:10] <hatch> ahh dinging all over the place
[19:11] <hatch> rick_h_ yep, you made some good points here
[19:13] <hatch> rick_h_ https://plus.google.com/hangouts/_/76cpj84oalco0dv6t5k2st3lgk?hl=en
[19:14] <hatch> there is a warning on ABS glue "do not smoke"
[19:14] <hatch> w t h
[19:19] <rick_h_> hatch: joining
[19:48] <hatch> rick_h_ what article is jc talking about?
[19:48] <hatch> on the tweeters
[19:49] <rick_h_> hatch: sec otp
[19:51] <hatch> sure np
[20:07] <kadams54> rick_h_ mentioned a utility for quickly injecting HTML fixtures into the container; I need a reminder what that is?
[20:08] <rick_h_> kadams54: makeContainer
[20:08] <kadams54> thanks
[20:21] <Makyo> jujugui feeling wretched, going to sit on the deck for a few, won't be around for pings.
[20:21] <hatch> okee cya
[20:21] <kadams54> rest up
[20:21] <rick_h_> Makyo: hope you feel better
[20:25] <rick_h_> hatch: benji did you guys have the LoC numbers you were chatting about the other day still?
[20:26] <rick_h_> actually, should have those in the irc log
[20:27] <hatch> not sure what you're referring to
[20:28] <rick_h_> hatch: weren't you and benji looking at how many lines of code was in the gui
[20:28] <rick_h_> hatch: oh, your blog post! that's right
[20:29] <hatch> ohh yeah
[20:29] <hatch> :)
[20:29] <benji> I can find them in my IRC log, but apparently you found them
[20:29] <rick_h_> thanks guy, I just nabbed them from hatch's blog post
[20:29] <rick_h_> guys
[20:29] <rick_h_> bah
[20:29] <rick_h_> EOD bring me home
[20:57] <kadams54_> Ditto
[21:59] <hatch> man the internet is trippin that FB bought Oculus
[22:02] <hatch> morning huwshimi 
[22:02] <huwshimi> Morning
[22:08] <huwshimi> rick_h_: Do you know what the card "create machine panel header view/widget" is? It sounds very much like the card I just completed. I know you switched them over because I took the wrong card.
[22:15] <huwshimi> hatch: Any ideas ^
[22:15] <hatch> umm looking
[22:16] <hatch> not a clue
[22:16] <hatch> they look the same-ish
[22:17] <huwshimi> :)
[22:18] <hatch> huwshimi the blocked card in Project 1 is no longer blocked
[22:18] <hatch> you could do that?
[22:19] <huwshimi> hatch: Yeah, that's my plan, I just wanted to know if I should do that other card first as it seems related...
[22:19] <hatch> yeah I can't figure out what it's pointing to that's not what you just did
[22:19] <hatch> I don't see any other 'header' in the mockups
[22:20] <huwshimi> yeah.
[22:21] <huwshimi> hatch: Your official EOD is not for a couple of hours right?
[22:22] <hatch> 38mins
[22:23] <rick_h_> huwshimi: that one is the header control in the machine view panel
[22:23] <rick_h_> huwshimi: that's at the top of all 3 columns in the machine view
[22:23] <rick_h_> huwshimi: let me know if you want to chat on it
[22:23] <hatch> there is no header for the three columns
[22:24] <huwshimi> rick_h_: Yeah, an imp call would be good.
[22:24] <huwshimi> rick_h_: Want me to invite you?
[22:24] <hatch> mind if I join?
[22:24] <rick_h_> huwshimi: k sec 
[22:24] <rick_h_> sure 
[22:24] <hatch> ohh NOW i see the header
[22:25]  * hatch doesn't think this is a very good ux 
[22:25]  * hatch hopes he is reading it wrong
[22:25]  * hatch probably is
[22:25] <rick_h_> huwshimi: link?
[22:26] <huwshimi> Trying...
[22:26] <hatch> he has to invite bcus he is from his tablet
[22:26] <rick_h_> k
[22:26] <huwshimi> rick_h_: https://docs.google.com/a/canonical.com/file/d/0B5yaFXSrLF38aVk4ZXJZY0tJZWJTUy1GVXlScmZRS21rUFJv/edit
[22:43] <hatch> I wonder if the machine view would be a good candidate for another instance of the viewlet-manager. With the header as a view and each column could be it's own view
[22:44] <hatch> then it would be another `new machineView()` to make the whole thing
[22:46] <hatch> that can be pieced together at a later time
[22:57] <huwshimi> hatch: What approach would you take to get other views to render to the new content panel?
[22:58] <hatch> maybe now would be a good time to do the viewlet manager 
[22:58] <hatch> hmm
[22:58] <hatch> let me stare at this mockup for a bit
[23:00] <hatch> ok so I have a different idea on how to do this
[23:01] <hatch> each column, including the header is a view (it will likely share a bunch of code via extensions) 
[23:01] <hatch> those views would be rendered and instantiated by a viewlet-manager instance much like the inspector instances are
[23:02] <hatch> there would be a 'right hand panel' subclass of viewlet-manager and then the machine view and charm details would subclass that again
[23:02] <hatch> (identical to how the inspector viewlet managers work)
[23:02] <hatch> yep that's how I'd do it
[23:03] <hatch> ^ huwshimi  does that mean anything to you? you weren't here for that stuff :)
[23:03] <huwshimi> hatch: It doesn't mean much :)
[23:04] <hatch> hmm ok ok - well... 
[23:05] <hatch> I would like another opinion on this before I send you down this path
[23:05] <rick_h_> hatch: we can take the view that huwshimi has and work with it. The viewlet-manager idea is interesting. I'm not up on what's left in the manager vs not so we should look into it
[23:06] <huwshimi> hatch: Well, I understand what you're saying, I just don't know how to implement it :)
[23:06] <rick_h_> hatch: so I'd suggest huw just work on the skeleton views
[23:06] <rick_h_> and then we'd pull it in/incorporate for full interaction/switching/etc
[23:06] <hatch> right....ok umm
[23:06]  * hatch thinks
[23:06] <rick_h_> hatch: but I don't think the viewlet manager would do well with multiple views available at the same time on the same slot
[23:06] <rick_h_> hatch: as it is now
[23:06] <rick_h_> hatch: so there's some things to think through and I would think they don't need to block huw up
[23:06] <hatch> well each column would be it's own slot
[23:07] <hatch> oh yeah for sure
[23:07] <rick_h_> hatch: right, but how would you layer for animation the views in the slots?
[23:07] <rick_h_> anyway, it's well past EOD and I need to go away before my family shoots me
[23:07] <hatch> huwshimi ok make three views which represent each column
[23:07] <rick_h_> but my thought on the matter since you bring it up :)
[23:07] <hatch> rick_h_ :) thx we can chat soon on it
[23:08] <hatch> huwshimi quick call?
[23:08] <hatch> easier than typing :)
[23:10] <huwshimi> hatch: I'm a little hesitant to put too much work into it until you and rick have bashed it all out...
[23:11] <huwshimi> hatch: I think I'll create a base view for now and get the header widgets working etc.
[23:11] <huwshimi> hatch: And then hopefully by the time I'm done there will be a better picture of how the rest should be structured...
[23:11] <huwshimi> Sound OK?
[23:12] <hatch> so build it in a way that each header is separate and not a row
[23:12] <hatch> else we won't be able to split it up into three columns
[23:12] <huwshimi> hatch: Well, each header will be an instance of a widget
[23:13] <huwshimi> widget/view?
[23:13] <hatch> hmm 
[23:13] <hatch> I'd go view in this case
[23:13] <huwshimi> Ok
[23:13] <huwshimi> I have a bug I need to fix before I work on this stuff anyway
[23:14] <hatch> alright, I'm going to step away for a bit but ping if you want to chat
[23:15] <huwshimi> hatch: Thanks :)
[23:17]  * huwshimi heads to the coffee shop for a bit.
[23:48] <rick_h_> hatch: https://algorithms.rdio.com/post/make/ is the article I RT on twitter that someone eles saw