[00:46] <rick_h_> morning huwshimi 
[00:46] <huwshimi> rick_h_: Hey!
[00:47] <rick_h_> huwshimi: glad you made it back safe and sound
[00:47] <huwshimi> rick_h_: Thanks. Me too!
[00:47] <huwshimi> rick_h_: Your trip went ok?
[00:48] <rick_h_> huwshimi: yea, was actually really nice. Had an empty seat next to me that I split with the guy 2 seats over
[00:48] <rick_h_> huwshimi: so was nice to have more leg room and such
[00:48] <huwshimi> rick_h_: Nice, I had the same thing :)
[00:48] <rick_h_> woot!
[00:48] <huwshimi> Yeah
[12:01] <hatch> morning
[12:01] <rick_h_> morning
[12:03] <hatch> I'm going to try and keep this new starting hour
[12:03] <rick_h_> lol, good luck!
[12:04] <hatch> haha thanks I might need it
[12:05] <hatch> hmm huw is saying that trunk is broken
[12:06] <hatch> oh and rick my fitbit stopped working again lol
[12:09] <rick_h_> yea, I can't dupe the trunk test failures. Tried normal and make clean-all
[12:09] <rick_h_> hatch: and :P on the fitbit
[12:22] <hatch> rick_h_: so any luck on the toggles?
[12:23] <rick_h_> hatch: yea, a little bit. I've got to get through dealing with the conflict ux with the multiple fields and then some tests and such
[12:23] <rick_h_> and get a formatter in there for the true/false to True/False
[12:24] <hatch> use css
[12:24] <rick_h_> ah, good call on that. 
[12:24] <hatch> text-transform: capitalize
[12:24] <hatch> I think that's it
[12:24] <rick_h_> yea
[12:51] <hatch> I find it irritating that my cell phone internet is like 3x the speed of my home internet :)
[12:51] <hatch> I can't wait to get fiber
[12:52] <hatch> same price, 2x the speed
[12:52] <bac> yeah, me neither.  oh, wait, that'll never, ever happen
[12:52] <hatch> lol
[12:52] <bac> hey benji, you have a moment to guichat?
[12:53] <benji> bac: sure, one sec, let me get my camera hooked up
[13:00] <gary_poster> heads up to jujugui world: I'm looking pretty carefully at the databinding code, particularly in conflict resolution.  if anyone is tempted to work around there, please lemme know.
[13:01] <rick_h_> gary_poster: ok, I'm in there currently, but doing little things atm. 
[13:01] <gary_poster> cool rick_h_ 
[13:01] <rick_h_> hatch: want to chat when you get a sec please
[13:01] <hatch> gary_poster: glad you are - we have been looking into refactoring that for a while
[13:01] <hatch> its scope has.....changed :)
[13:01] <gary_poster> cool hatch.  I'm not trying to do a heavy refactor, just trying to get a number of edge-ish cases working.
[13:02] <rick_h_> hatch: got a sec?
[13:04] <bac> hi gary_poster, can you join benji and me in guichat?
[13:04] <gary_poster> ok bac
[13:05] <hatch> rick_h_: yup guichat?
[13:05] <rick_h_> hatch: it's busy, will send invite
[13:05] <hatch> cool
[13:05] <hatch> we should almost make a guichat2 :)
[13:09] <sinzui> Holy fsck! I have a crippled computer
[13:10] <sinzui> The update this morning borked my keyboard. I just spent an hour trying to get capital letters working.
[13:11] <sinzui> Everytime I pressed shift, the menus opened. I hacked dconf and restarted. Then every time I pressed super the menus started
[13:11] <sinzui> opening
[13:12] <sinzui> I suspect I am on xmir and it doesn't respect Xmodmap
[13:15] <rick_h_> hatch: so....I could bind the event in the viewlet render call ... maybe ... just sayin
[13:16] <hatch> lol no! becuase then there is no way to clean it up :)
[13:16] <hatch> fight the pain
[13:16] <rick_h_> ah $#@$@#$@#
[13:16] <hatch> fight the pain!
[13:16]  * rick_h_ goes back to swearing at things
[13:19] <rick_h_> hatch: but viewlets have a destroy stub and it gets called on filling slot?
[13:20] <rick_h_> hatch: and on the viewlet manager destructor
[13:20] <rick_h_> hatch: so I can bind in render and add cleanup to a custom destory function in the viewlet def?
[13:20] <hatch> oh I suppose you 'could' find a way
[13:20] <hatch> dont' really see what that gets you though
[13:20] <hatch> it really adds more complexity because now there would be two places events are being attached
[13:21] <rick_h_> hatch: yea, a 'right' place and a 'wrong' place and it's easier to test the viewlet stand alone
[13:21] <rick_h_> hatch: ignore me...carry on. Thanks for the tip
[13:21] <hatch> I dont' think so because the viewlet is only supposed to be a configuration
[13:21] <hatch> :)
[13:22] <rick_h_> it's not, too bad, move along. :)
[13:22] <hatch> rm -rf rick_h
[13:22] <hatch> moved along
[13:22] <hatch> :P
[13:24] <hatch> oh hey it's the apple conference today
[13:26] <hatch> hmm test fails....looks at tests....test shouldn't have passed before....oops
[13:26] <hatch> :)
[13:30] <hatch> I wish when I walked into my room it would turn off email and G+ notifications on my phonhe
[13:30] <hatch> room being office
[13:30] <rick_h_> hatch: getting there. With the bluetooth unlock/safe zones the ground work is there to start building bt based profiles. 
[13:31] <rick_h_> hatch: basically need a BT target on your desk that if it's attached it silences events down a notch
[13:31] <hatch> hmm
[13:31]  * hatch quickly files patents
[13:32]  * hatch quickly learns Java and writes android app
[13:32]  * hatch retires into obscurity after selling millions
[13:44] <Makyo> That was fast.
[13:46] <hatch> yeah I'm a pro like that
[13:46] <hatch> oh crap I was supposed to be in obscurity
[13:46]  * hatch goes obscure again
[13:47] <hatch> btw- it feels like fall here.....*sqweee* winter is coming!
[13:48] <rick_h_> ugh, high is supposed to hit 35.5C today (96F)
[13:48]  * rick_h_ is not happy
[13:48] <rick_h_> today/tomorrow, then I get fall back.
[13:49] <hatch> yikes!!
[13:49] <Makyo> Yeah, it's delightfully rainy and cool here.  Brought back a bit of the weather.
[13:49] <hatch> OO today is looking like a good kiteboarding day
[13:49] <hatch> *caugh caugh*
[13:49]  * hatch isn't feeling good
[13:49] <hatch> *caugh caugh*
[13:55] <jcsackett> rick_h_: it always shocks me when you northerners have a hotter day than us.
[13:56] <rick_h_> jcsackett: and makes me sad :(
[13:56] <hatch> rick_h_: see #3 http://www.healthycomputing.com/office/setup/monitor/ (I think it was you and I discussing this)
[13:56] <rick_h_> hatch: yea, with huw
[13:56] <rick_h_> hatch: cool, yea I'm checking mine and that's about right
[13:57] <hatch> yeah mine is a little high...maybe 1" but thats because it's too damn big for the desk and I can't get it any lower
[13:57] <hatch> lol
[13:58] <hatch> rick_h_: oh there is an exception ""Exception: If you use a large monitor (20" or larger), position your monitor so that the top of the viewing area is about 3" above eye level.""
[13:58] <hatch> hehe 20" or larger is a 'large monitor'
[13:59] <rick_h_> hatch: https://www.dropbox.com/s/sj5ayprdxsj6b68/2013-09-10%2009.57.39.jpg is with my phone camera right about eye level
[13:59] <rick_h_> oh hmm, maybe I need to move them up a bit, though these are only 21"ers
[13:59]  * hatch hates you and your setup
[14:02] <hatch> I mostly hate it because I can't do it
[14:02] <hatch> lol
[14:02] <rick_h_> it's ok, I'm never happy with it. Always something else. Trying to stop here and be happy
[14:03] <hatch> isn't that the western way?
[14:03] <hatch> we are never happy with what we have?
[14:03] <hatch> lol
[14:03] <rick_h_> guess so, but I realize it and get annoyed with myself over it.
[14:03] <hatch> truth!
[14:04] <hatch> maybe that's why I keep cell phones for 3 years
[14:04] <hatch> to try and prove to myself I'm not like that lol
[14:07] <jcsackett> orangesquad: i resolved my lp-propose goofiness. can i get a review of https://code.launchpad.net/~jcsackett/charmworld/review-queue-metrics/+merge/184785 ?
[14:07] <jcsackett> feels good to be using lp-propose again, honestly.
[14:08] <sinzui> freak
[14:08] <abentley> jcsackett: aww, you're so sweet.
[14:08] <jcsackett> abentley: :-P
[14:08] <abentley> jcsackett: looking.
[14:08] <jcsackett> abentley: thanks.
[14:09] <jcsackett> sinzui: lp-propose: a few seconds. lbox propose -cr: go make coffee.
[14:10] <sinzui> jcsackett, IRC does not properly convey my sarcasm 
[14:10] <hatch> jcsackett: you just hate lbox because your tests always fail :P
[14:11] <sinzui> bugger. I still have a broken keyboard and now I cannot see out of me left eye.
[14:11] <jcsackett> hatch: aaah, is that why you so frequently forgo new tests in your branch? :-P
[14:11] <hatch> rofl
[14:11] <rick_h_> oooh, burnnnnn
[14:12] <hatch> yeah it stings a little
[14:12] <jcsackett> lemme get you some lidocaine for that.
[14:19] <benji> bac: Huw's follow-up branch has landed.
[14:19] <bac> benji: thanks
[14:38] <abentley> sinzui: My computer is trying to protect me from Saucy.  Upgrade-manager keeps dying with "Real-time signal 0".
[14:39] <sinzui> ouch
[14:39] <abentley> jcsackett: Juju gui bot is me.  Doh.
[14:39] <sinzui> Maybe it knows keyboards are screwed.
[14:40] <jcsackett> abentley: dig, thanks, and good points all.
[14:40] <sinzui> The keyboard options to configure keys is missing in saucy. The documentation still described the old way to get to the settings. I found some setting in dconf, but I am clueless about writing the gnome codes by hand
[14:42] <bac> benji: it looks like you or huw fixed the readme width for charms but not bundles.
[14:42] <benji> bac: arg!  I should have remembered that.  Yeah, he only did the one.
[14:42] <benji> bac: I'll self-review a branch that fixes that right now.
[14:43] <bac> benji: cool
[14:43] <arosales> Makyo, gary_poster: hello, did you have any getting started with the GUI docs that evilnickveitch could include in the juju documentation?
[14:43] <bac> benji: and he went back to 9 not 8.  i guess that was intentional
[14:43] <Makyo> arosales, I have a branch started, but not completed.
[14:44] <benji> bac: it was; because 8 causes unwanted line wrapping; 9 does too, when font size is increased
[14:44] <gary_poster> arosales, was encouraging Makyo to get that out to you, though we are behind on inspector so I'm prioritizing that now.  hopefully he can get some time for it later this week, yeah, Makyo?
[14:45] <arosales> gary_poster, Makyo: thanks or the update. No rush, just wanted to follow up.
[14:45] <gary_poster> cool, thanks arosales 
[14:47] <Makyo> gary_poster, arosales I'm on swap Wed-Fri, but will see what I can do tonight.
[14:47] <gary_poster> Makyo, oh right!  sorry.  Next week then. :-)
[14:48] <arosales> gary_poster, no worries if it lands next week
[14:48] <arosales> sorry
[14:48] <arosales> Makyo, no worries if it lands next week
[14:49] <gary_poster> :-)
[14:50] <hatch> so close to getting all of these tests fixed
[14:50] <hatch> fixing tests after refactoring is making me dislike agile
[14:50] <hatch> agile this! *hulk smash*
[14:52]  * sinzui restarts to verify he has beatdown mir+gnome+unity
[14:58] <hatch> man I friggen love databinding
[15:05] <luca__> gary_poster: do you need the inspector lists that you created last week?
[15:06] <gary_poster> luca__, no thank you, took a photo
[15:06] <luca__> gary_poster: ok
[15:13] <adeuring> bac, benji, abentley: could one of you have a look at this MP: https://code.launchpad.net/~adeuring/charmworld/fixed-interfaces-mapping/+merge/184805 ?
[15:13] <benji> adeuring: I'll take a look
[15:19] <rick_h_> hatch: guichat please?
[15:20] <hatch> sure
[15:25] <bac> benji: staging has been updated to r392
[15:25] <benji> cool
[15:36] <bac> benji: go here: http://staging.jujucharms.com/search?search_text=precise  , a search for 'precise'.  marvel at the first hit.
[15:36] <benji> huh
[15:38] <benji> bac: it is because the description of one of the config strings includes the word "precise"
[15:38] <bac> ok, i thought i looked there
[15:38] <benji> such are the vagaries of full text search
[15:46] <bac> benji: staging looks good to me.  i'm going to request production update to r392
[15:47] <benji> k
[15:49] <benji> adeuring: your branch looks good to me
[15:49] <adeuring> benthanks
[15:49] <adeuring> benji: thanks
[15:52] <gary_poster> jujugui call in 9
[15:59] <gary_poster> jujugui call in 1
[16:15] <bac> sinzui: when i create an RT i get an error message (Couldn't load or create user: Must specify 'Name' attribute)  the RT gets created, though.  do you know what might be wrong?
[16:15] <bac> i put 'bac' as requestor and it shows that as the owner
[16:16]  * bac hates rt.
[16:16] <sinzui> bac, I think you need to provide your email address
[16:16] <bac> will try next time
[16:17] <sinzui> bac, I sometimes forget requester. It has never stopped webops.
[16:41] <abentley> sinzui: I've updated the environments.yaml so that juju doesn't need novarc to be sourced.  I've also added a command, "jnova", that uses the settings from environments.yaml to run "nova".
[16:42] <sinzui> fab
[16:43] <abentley> sinzui: That means that "juju switch" is all you need, whether you're switching from one region to another or one set of user credentials to another.
[16:44]  * sinzui pulls
[17:04] <hatch> jujugui: requesting two reviews and a large QA on https://codereview.appspot.com/13373050/ QA will need to be someone with a go env setup.... rick_h_ ;)
[17:09] <rick_h_> hatch: k, will be a few 
[17:09] <hatch> rick_h_: yeah no rush it's a big one
[17:10] <hatch> jujugui anyone else sitting on reviews they need?
[17:11] <gary_poster> not i, but thank you
[17:17] <hatch> oh and if anyone doing my reviews wants a walk though I'll be more than happy to help :)
[17:24] <hatch> bcsaller: if you have time I'd love it if you could review my branch
[17:28] <hatch> gary_poster: I need to wait for that branch to be reviewed/landed before I work on the follow-ups is there another card you would like me to work on in the mean time?
[17:29] <gary_poster> looking
[17:30] <gary_poster> hatch, what was "ghost save functionality," do you remember?
[17:30] <hatch> yeah, it doesn't do anything
[17:30] <hatch> it just closes the inspector
[17:30] <bcsaller> hatch: I'll start on it in a minute, I've seen parts of this before so that helps :)
[17:30] <hatch> at least that's what it 'was' not sure if that's still valid
[17:30] <hatch> bcsaller: awesome thanks :)
[17:31] <gary_poster> hatch, yeah, good enough for now.  it is "saved" in that you can open it up and see it again.  I am not keen on needing to use env annotations to make these shared, at least for now.  maybe later.  However...
[17:31] <gary_poster> hatch, luca says that MS wants us to move "expose" from the config page to the front "destroy" section
[17:32] <gary_poster> I think it is on newer visuals, maybe?
[17:32] <gary_poster> I wasn't quite sure how to do that on the face of it
[17:32] <gary_poster> but maybe you can whip it out quickly?  
[17:32] <hatch> that can't be done until after rick_h_ is done with his branch because he modifies that code
[17:32] <hatch> so there will be huge conflicts
[17:33] <rick_h_> hatch: well do me a favor, I'm setting up a MP so I can go through the stuff changed and get tests updated. If you can pull/QA that'd be helpful
[17:33] <hatch> sure, what's the branch?
[17:34] <rick_h_> hatch: lp:~rharding/juju-gui/update-conflict-ux
[17:34] <hatch> moving expose to the destroy section sounds very odd to me, I think I'll need to see these new designs
[17:34] <hatch> rick_h_: cool, on it
[17:34] <hatch> does this have trunk merged in?
[17:34] <rick_h_> hatch: hmm, not today I guess. /me goes to do that 
[17:35] <rick_h_> hatch: merged and pushed
[17:36] <hatch> woah 64bit chip in the new iphone
[17:37] <hatch> rick_h_: thanks
[17:59] <hatch> rick_h_: so is the expose section supposed to have True/False ?
[17:59] <hatch> it looks odd to me
[18:00] <rick_h_> hatch: yea, I went back and forth. When you leave that out, it looks strange in two lines
[18:00] <rick_h_> hatch: and I figured I'd make it consistent and we can update with UX input once it hits coming soon
[18:00] <hatch> and in the ghost - 'Use the default configuration?' has that as well
[18:01] <hatch> and when it's checked(true) I can still toggle the debug checkbox
[18:01] <hatch> that checkbox needs to be disabled
[18:01] <rick_h_> hatch: yea, consistent design to start, make it inconsistent once told to :/
[18:01] <rick_h_> hatch: yea, finding that in tests right now, adjusting
[18:01] <rick_h_> the disabled part
[18:02]  * gary_poster CHEERS that prototype now actually fixes all the things he wanted it to fix.  YAAS!
[18:02] <hatch> the 'import config file' button looks disabled and doesn't turn the cursor into a pointer (not sure if your branch or something else in trunk)
[18:02] <gary_poster> Now for a few branches...
[18:02] <hatch> w00t w00t
[18:02] <gary_poster> prototype is 493 line diff, so hopefully won't be too bad to actually get out there...
[18:03] <hatch> I still donlt like these true/false things - I know they aren't your fault rick_h_ but you're the only one around I can complain to right now :P
[18:03] <rick_h_> hatch: :P well I want to get it up in front of UX folks and get feedback. Wouldn't be the first time design needed tweaking
[18:04] <rick_h_> yay! existing tests now pass. Time to write the new ones
[18:04] <hatch> I mentioned it in the mockups that there is no 'division' because there is no large white block...they ignored me :'(
[18:04] <hatch> WAHHHHHH
[18:04] <rick_h_> hah, no one loves hatch...he's going to eat some worms
[18:04] <hatch> lol is that a thing down there?
[18:05] <rick_h_> kids thing "No body loves me, everybody hates me, I'm going to eat some worms..." Wasn't it a book or something? /me doesn't recall
[18:05] <hatch> maybe some crazy american book
[18:05] <rick_h_> hatch: ok, updated with disabled on the field
[18:06] <rick_h_> overall though QA is pretty clean?
[18:06] <hatch> yup, just checking conflict ux now
[18:06] <hatch> also didn't qa in IE yet
[18:06] <hatch> but i'll do that once the full thing langs
[18:06] <hatch> lands
[18:06] <rick_h_> k, all good. Sure it'll need it with review
[18:06] <rick_h_> but good to have another set of eyes on it
[18:06] <rick_h_> hatch: but if you need my stuff you can grab this branch to start with
[18:07] <rick_h_> I'll have tests today and probably have to get review/qa tomorrow.
[18:07] <hatch> I have no idea what i'm supposed to do with this conflict
[18:07] <hatch> I see a ! then I click on it and....?
[18:07] <hatch> it just goes away
[18:07] <rick_h_> yea, there's nothing to do. It's just a 'notice'
[18:07] <rick_h_> for a checkbox there's no choice to make, do you want to change it or not?
[18:08] <rick_h_> if someone changes behind you, we just say 'hey, this was changed while you're working on it'
[18:08] <hatch> yeah I guess...but that ! doesn't really mean anything
[18:08] <hatch> maybe we need a tooltip ?
[18:08] <rick_h_> well once gary_poster's lands it won't show it when the values are equal
[18:08] <hatch> "this means there is a conflict"
[18:09] <rick_h_> so the *only* time you should see it is: "1 - you change from false to true, 2 - someone else sets it to true, 3- someone else sets it to false and saves, 4 - you get a conflict notice"
[18:09] <hatch> right so it's very rare so it's even more important to have some help text
[18:09] <rick_h_> bah, and we're offially over 90F...I hate mother nature
[18:10]  * hatch thinks you should probably hate humans who probably contributed to making it so hot ;)
[18:10] <benji> gary_poster/bac: I've been trying to fight through a headache, but I'm going to have to go lie down now
[18:10] <gary_poster> hatch, agree, and my branch makes even more things automatic, but I think that needs to be post-release.  Could be wrong.
[18:10] <gary_poster> benji, ok, feel better
[18:11] <hatch> gary_poster: yeah we can work towards it for sure - just as long as design also see's the issue :D
[18:11] <gary_poster> hatch, I think they will when we show it to them
[18:12] <hatch> rick_h_: there are some styling issues with the input conflict ux....probably not your branch though
[18:12] <hatch> the checkmark spills out of the dropdown
[18:12] <rick_h_> hatch: ok, good to know. I didn't think I touched that but will double check on comingsoon
[18:12] <rick_h_> hatch: if you can check/file a bug would be appreciated
[18:13] <hatch> can do!
[18:14] <hatch> rick_h_: yah it's ugly there too
[18:14] <hatch> :D
[18:14] <rick_h_> thank goodness
[18:14]  * rick_h_ wants to get this branch wrapped up, he'll never be able to look at checkboxes again after the last two weeks
[18:15] <bac> hi gary_poster, regarding upgrading jujucharms.com, for juju-gui the latest tarball is 0.9.0.  we want to upgrade to it.  do we need a new version of the charm as well, i.e. r76?
[18:15] <gary_poster> hi bac.  no, we do not (though +1 on verifying that the old charm is unnecessary).
[18:15] <bac> gary_poster: did you see the call for mentors for the sparkcon "learn to code" event this weekend?
[18:15] <gary_poster> bac, no
[18:15] <hatch> gary_poster: you never did get back to me about a ticket to tackle :)
[18:16] <bac> gary_poster: trizpug mailing list.  looks like fun, maybe.
[18:16] <gary_poster> hatch, I did too!  you just didn't like any of my suggestions :-P
[18:16] <hatch> lol!
[18:16] <hatch> it's not that I didn't LIKE them....
[18:16] <gary_poster> heh
[18:17] <hatch> do we have a design for moving the expose button?
[18:17] <gary_poster> I think so.  looking
[18:17] <hatch> I really can't do anything about it until rick's branch lands but I'd like to take a peek
[18:20] <gary_poster> hatch, you could work from his branch.  that's what I sometimes do.  Anyway, here, look at the second inspector from the top left here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1YWJqdXg1QzdLYkU/edit?usp=sharing
[18:20] <hatch> maybe his branch will fail review :P
[18:20] <hatch> looking
[18:20] <gary_poster> "expose" is right above "destroy"
[18:21] <hatch> ohhh I see
[18:21] <hatch> it's kind of hidden and out of the way
[18:21] <hatch> maybe that's good?
[18:21] <bac> hatch: you think we can build a MAAS cluster of 64bit iphones as a compute farm?
[18:22] <hatch> would people want to toggle it?
[18:22] <rick_h_> yea, you don't normally expose that many services
[18:22] <hatch> bac: a very power efficient compute farm? :D
[18:23] <bac> gary_poster: rts 64505 and 64512 logged for upgrading manage.jujucharms.com  and jujucharms.com.  waiting on webops.
[18:23] <gary_poster> bac awesome thank you
[18:23] <bac> hatch: my current phone is slowly losing functionality so i'm in the market for a replacement
[18:24] <hatch> bac: I'd highly recommend the HTC One
[18:24] <hatch> picked one up 2 weeks ago and loving it
[18:24] <rick_h_> I'm waiting for the nexus 5 next month, one is good, the new motox is cool, but limited availability right now
[18:24] <hatch> rick_h_: I'd remove 'True' from the ghost config template (it should be set by the databinding)
[18:25] <hatch> rick_h_: 5" is just too big - I do like how the iphone is a 4" but I haven't really found the One to feel that large for some reason
[18:25] <rick_h_> hatch: hmm, that wasn't there. 
[18:25] <rick_h_> hatch: well the dimentiions of the N5 are smaller than the N4 with a larger screen
[18:25] <hatch> Im just doing a psudo code review to see if I want to work from your branch :P
[18:25] <hatch> oh really? I thought it was mirrored off of that new Sony phone
[18:26] <rick_h_> hatch: LG thing, but if the fcc filings are correct, then yea. less bezel ftw
[18:27] <hatch> I'm confused by the requirement for skipconflictux on elements that don't have conflict ux markup
[18:27] <hatch> the expose template
[18:28] <rick_h_> hatch: because they've been set/unset/etc 5 times in getting this branch worked out
[18:28] <rick_h_> hatch: but things like marking 'changed' also apply
[18:28] <rick_h_> and the ! indicator isn't part of the conflict resovle html
[18:28] <rick_h_> so all elements have the potential for conflict-ux
[18:29] <rick_h_> hatch: the True on the ghost is for the default config box, that's not data bound
[18:29] <rick_h_> how would data binding make me not need that
[18:29] <rick_h_> ?
[18:29] <hatch> oh woops
[18:31] <bac> hey benji, do you have all of the fiddly bits necessary to access staging.jujucharms.com?
[18:31] <bac> benji: i mean to manage via juju
[18:34] <hatch> rick_h_: do change events not bubble?
[18:35] <rick_h_> don't know for sure, I'd imagine no since it's tied to a specific input
[18:35] <hatch> all events are :)
[18:35] <rick_h_> http://stackoverflow.com/questions/265074/does-the-onchange-event-propagate
[18:35] <hatch> https://developer.mozilla.org/en-US/docs/Web/Reference/Events/change
[18:35] <hatch> according to this 'yes'
[18:37] <hatch> so if it truely does then you can put that event listener in the environment.js file and remove all of that event stuff in the viewlet manager
[18:40] <rick_h_> so http://jsfiddle.net/nfakc/18/ seems to work and bubble in IE10
[18:41] <hatch> awesome so you can remove all of that event attach stuff
[18:42] <hatch> my guess - at one point it didn't bubble and noone has gone back and updated those old docs
[18:42] <hatch> s/docs/questions
[18:42] <rick_h_> so seems to buble in all three. Will look at it though the point was to stop putting event stuff in environment.js as it's beyond evil. I can use a delegate or something though to update it as one event vs each chcekbox
[18:43] <hatch> no no no no, when we move the event stuff it'll be done properly in the viewlet manager, not just one event tacked on separate from the rest
[18:44] <rick_h_> why would the viewlet manager do it? Each viewlet needs to control wtf it does. I'm failing to see how moving the evil from one file to another file that's not the locatino of the code using it makes any sense at all
[18:44] <hatch> because the viewlet manager will parse an event config in each viewlet and attach it to the viewlets container
[18:44] <rick_h_> you create a ghost-inspector, it wants to watch for boolean inputs...so the event is there. 
[18:44] <hatch> when the viewlet is destroyed the manager will then go and clean those up
[18:45] <rick_h_> how many files do I have to have open to see wtf is going on. No wonder everyone hates events. They're not located next to the owner
[18:46] <hatch> the event configuration will be moved from the environments.js file and split up into each viewlet
[18:46] <rick_h_> anyway, argument for another day. I need to get these tests going. I want to test the veiwlet and it's event handling properly without a viewlet manager, or environment, or anything else that needs a bunch of stuff. I should be able to hand a viewlet a container and model and test it. 
[18:46] <hatch> no because a viewlet is a configuration object
[18:46] <hatch> that's it
[18:47] <hatch> so you can unit test the utility methods which are mixed in
[18:47] <hatch> and you can integration test the whole stack
[18:48] <hatch> it was designed that way to be very easy to test
[18:49] <rick_h_> except that it's not currently. The tests don't test the render method or any helpers because they need to go through a viewlet manager to figure out what's up. Then there's the pain of the viewlet manager needs to pull in all viewlets and there's interactions hidden in there. 
[18:50] <hatch> that's because you're trying to write a unit test without a proper mockup
[18:51] <hatch> or you're writing an integration test and don't want to pull in everything
[18:51] <hatch> really, it makes sense I promise :)
[18:54] <rick_h_> I understand what you're saying. And when you say "it's just a configuration object" I know it sounds light/easy. However, in practice, it's a mess. I know it'll get better with refactoring, but I don't understand why we're against events and callbacks responding to those events living in the viewlet itself. It's a mini-view without the YUI overhead. Syncing code between inspector.js, evironment.js, the template, the viewlet, an
[18:54] <rick_h_> the idea is great, in practice there's some love needed
[18:55] <hatch> because then you have to create an instance of the viewlet. if you want to unit test a method in a mixin....just pass the data into the method and test what comes out. That's what a unit test is
[18:55] <hatch> anything more is an integration test
[18:56] <hatch> the real issue we have is that we don't have a proper mock structure which we can count on cross our test suite
[18:56] <rick_h_> the viewlet is doing sync with data binding, the template, change events. There's no such thing as unit testing this viewlet at this point. 
[18:57] <hatch> that's an integration test
[18:57] <hatch> so write an integration test
[18:57] <rick_h_> hatch: and I don't disagree, but small localized integration tests I can count on to break are good things :)
[18:57] <rick_h_> right, but I don't want to integrate with every viewlet in the system
[18:58] <hatch> so you want an integration test that only integrates the things you want? :D
[18:58] <rick_h_> it's like a widget. You can unit test some bits, but for the most part, you've got to stick it on the page and fake the interactions to amke sure it behaves as you expect
[18:58] <rick_h_> it's an interactive structure. 
[18:58] <rick_h_> by its very nature
[18:59] <hatch> that's right
[18:59] <hatch> I don't really see what the issue is here
[18:59] <hatch> if you want to write a unit test - put the method in a mixin
[18:59] <hatch> if you want to write an integration test....well that already works
[19:00] <rick_h_> so you want me to do some mixin for updating boolean input fields?
[19:00] <rick_h_> and move the event that's bound there to there?
[19:00] <hatch> that's an integration test
[19:00] <hatch> the input field needs the template, the databinding engine, viewlet manager, viewlet
[19:01] <rick_h_> hatch: no, it's in integration test that needs a render call and a single simulate call. 
[19:01] <rick_h_> it doesn't need data binding, it doesn't need the viewlet-manager
[19:02] <hatch> well the events aren't in the viewlet config so you can't do that
[19:02] <hatch> you need the manager to bind the events
[19:02] <hatch> that's just how it works
[19:02] <rick_h_> I bind the event in the render() call. I don't need the manager for it at all
[19:03] <rick_h_> that's not how the current code works :)
[19:03] <hatch> yeah but that's wrong
[19:03] <rick_h_> lol
[19:03] <rick_h_> but it works and I don't have to bring in another monolilthic module of code to make sense of it all :)
[19:03] <bac> gary_poster: jujucharms.com is upgraded.  i'm not sure what the key differences are to verify.  it is up and running.
[19:04] <gary_poster> bac, thank you.  the two highlights are search autocomplete and IE support.
[19:04] <hatch> just because you don't like the architecture of the system doesn't mean that you can just go and hulk smash things to make it work the way you expect
[19:04] <hatch> we already know we need to put the event config objects in the viewlets
[19:04] <rick_h_> hatch: except you've agreed they need to change and the current system is flawed. If there's a better place I'm all for it. 
[19:04] <hatch> but that will still need the manager to instantiate it
[19:04] <bac> gary_poster: autocomplete works.
[19:04] <gary_poster> cool bac thanks.
[19:05] <bac> don't have easy access to IE to test.  perhaps hatch can
[19:05] <hatch> yup I can
[19:05] <rick_h_> bac: I can pull it up, have IE open now
[19:05] <bac> thanks y'all
[19:05] <hatch> cool rick_h_ can do it because i'll have to boot up the laptop
[19:06] <bac> so have we made the site HiDPI friendly?  it looks amazingly sharp now
[19:06] <hatch> bac: well the svg's should be sharp but the rest is the same
[19:06] <hatch> actually
[19:06] <rick_h_> bac: looks good, just went through search/auto complete, deployed a couple, build/destroy a relationship
[19:06] <hatch> I think the only raster graphics we use are some icons
[19:07] <rick_h_> bac: let me know if there's anything else I need to check. 
[19:07] <bac> rick_h_: that should do it.  thanks
[19:07] <hatch> icons meaning UI stuff, not charm stuff
[19:07] <rick_h_> yea, the +, ^ v and such
[19:08] <gary_poster> rick_h_, hatch, I agree that we want to change the viewlet event approach for later, and I agree with hatch that we should not introduce a new approach now but stick with what we have, unless we have a specific branch that is about proposing a new approach.  Please don't intro a third approach we all have to find and keep track of as part of another unrelated task.  Does that seem reasonable rick_h_ or do you have s
[19:08] <gary_poster> ome concerns, or maybe I misunderstand what you all are talking about?
[19:09] <rick_h_> gary_poster: working on it. I'm trying to get tests going and then will look back at it. 
[19:09] <gary_poster> cool thanks rick_h_ 
[19:10] <rick_h_> gary_poster: I think you understand, I'm just being a bull headed fool about never adding an event to environment.js because it's horrible imo and hatch wants me to follow design  so we ended up going at it a bit :)
[19:10] <hatch> I like our.....discussions
[19:10] <rick_h_> and the tests sit and wait while we fill up irc
[19:10] <gary_poster> rick_h_, heh, ok cool.
[19:10] <hatch> :)
[19:11] <hatch> if I wanted to propose that the juju docs use local configuration as the default install who would I propose that to?
[19:11] <hatch> ^ gary_poster ?
[19:11] <rick_h_> hatch: marco and evilnick
[19:11] <gary_poster> hatch, you could try evilnick.
[19:12] <gary_poster> at the least he'd be able to tell you who else you need to convince :-)
[19:12] <hatch> ok cool will do - my idea is that local provider doesn't require you to set up an ec2 account just to try it out
[19:22] <hatch> I think I screwed up my juju install
[19:22] <gary_poster> hatch, btw, great task: review Huw's gui branch and land it. :-)
[19:23] <hatch> I get `error: flag provided but not defined --show` when I try and run `juju generate-config --show`
[19:23] <hatch> -v --version
[19:23] <hatch> no flags work :/
[19:23] <rick_h_> hatch: yea, what are you running? what's the --version?
[19:23] <rick_h_> oh, you can't run version?
[19:23] <hatch> rick_h_: I get that error
[19:23] <hatch> yeah
[19:23] <rick_h_> dpkg -l | grep juju
[19:24] <hatch> juju, juju-0.7, juju-core
[19:24] <rick_h_> ok, so that's old
[19:24] <hatch> weird I JUST installed
[19:25] <rick_h_> hatch: from the ppa?
[19:25] <rick_h_> so I'm using sudo add-apt-repository  ppa:juju/devel
[19:25] <hatch> oh I used /stable
[19:25] <rick_h_> but there's also ppa:juju/stable
[19:25] <hatch> so I'll remove juju and juju-0.7
[19:25] <hatch> and just leave core?
[19:25] <rick_h_> oh hmm, I thought 1.0 was in stable?
[19:25] <hatch> I thought I could have both installed
[19:26] <rick_h_> I've not messed with both. It seems messy and more trouble and I just abuse Makyo for my pyjuju qa
[19:26] <hatch> ok so I'll remove the first two then
[19:26] <Makyo> My setup is pyjuju installed from apt in /user/bin/juju and core installed in $GO_HOME via go install ./...
[19:26] <Makyo> FWIW
[19:27] <hatch> looks like I'll have to remove and reinstall core as well
[19:28] <hatch> hmph nope still broken
[19:29] <hatch> what version of ubuntu is this...
[19:29] <hatch> 12.04
[19:29] <hatch> core supports 12.04 right?
[19:31] <hatch> oh well I'll get back to that later
[19:31] <gary_poster> hatch, I'd get a newer one.  raring or saucy.  we support precise as host
[19:31]  * hatch really doesnt' want to upgrade his vm
[19:31] <hatch> :)
[19:31] <gary_poster> make another one :-)
[19:31] <hatch> guess I could make a new one
[19:31] <hatch> haha
[19:31] <gary_poster> or clone
[19:32] <hatch> gary_poster: I can't seem to find huw's branch in my email
[19:32] <hatch> do you know what its called?
[19:33] <hatch> I only have ones of his which are submitted
[19:33] <gary_poster> hatch https://code.launchpad.net/~huwshimi/juju-gui/inspector-style-merge
[19:33] <hatch> oh no lbox
[19:34] <hatch> that would be why
[19:34] <gary_poster> hatch mentioned in his email with subject "Trunk broken - branch for review"
[19:34] <hatch> ohhhhh right right woops
[19:35] <hatch> bcsaller: re your comment on object order - according to the spec the order of an object is not guaranteed
[19:35] <hatch> although I've never found that to be true
[19:35] <hatch> :)
[19:36] <hatch> but that did require me to sort that list even though the values were there
[19:36] <bcsaller> hatch: I know that, but I actually thought deepEquals did a key oriented compare 
[19:36] <hatch> that's what I thought too....but it made me change the order
[19:40] <hatch> bcsaller: did you want me to move that unit stuff into the init in this branch or a follow-up?
[19:40] <bcsaller> hatch: I think it will be a small delta, do you feel alright doing it now? It trims a few checks out of your branch
[19:41] <hatch> yeah I think you're right - it's the proper way to might as well do it now
[19:42] <hatch> bcsaller: also re your comment on the error split uglyness - you didn't have a better approach right? That was just a comment?
[19:43] <bcsaller> hatch: yeah, just indicating we need to follow up on that talk because this won't last in the real world
[19:43] <hatch> well it'll last until they change it lol
[19:43] <hatch> so....probably next week :P
[19:43] <hatch> "oh we didn't like colons, so we switched to to pipes"
[19:43] <hatch> :P
[19:45] <hatch> great comments, I'll reply in the reviews but I'm pretty sure I'll be implementing all of the changes
[19:52] <hatch> oh poo a CI failure
[19:52] <bac> benji, gary_poster: the charmworld api_search and the interesting, et al, lists all have bundles and charms intermingled, with the 'doctype' field specifying one from the other.  the search method called from site search box is the only one that separates the two.
[19:53] <gary_poster> bac I feel that's good enough for a start, thank you.  Do search results include match scores in case we want to join them?
[19:54]  * hatch looks slyly at gary_poster....."was your branch QA'd in IE10?"
[19:54] <gary_poster> hatch, no I have no IE 10 here, sorry :-( problem?
[19:55] <hatch> yeah CI failed
[19:55] <hatch> looks like we really need to require that IE QA
[19:55] <bac> gary_poster: it does not look like they do
[19:55] <gary_poster> hatch, we do, I just didn't follow it.  Though, I suspect that this is intermittent on the face of it: TestNotifications is not something I should have touched
[19:57] <hatch> ahhh gotcha gotcha
[19:57] <gary_poster> I didn't follow it because I don't have it on this machine; I don't have it on this machine because I don't usually code that much any more; I don't code that much any more because it is not my main job; so the solution is that I should never code at all any more. :-)
[19:57] <hatch> rofl!!!
[19:57] <hatch> love the justification
[19:57] <gary_poster> hatch, could you or rick_h_ give it a whirl on IE 10 for me and let me know how it goes?
[19:58] <hatch> yeah I can do it
[20:00] <gary_poster> ty
[20:01] <Makyo> jujugui A little branch in need of reviewing: https://codereview.appspot.com/13413045 Thanks in advance
[20:11] <hatch> gary_poster: I can't see what this things issue is, I'll refire it off again
[20:11] <gary_poster> hatch, oh, you duped?
[20:11] <gary_poster> oh, you mean, you didn't dupe
[20:11] <hatch> yeah it all works as expected
[20:11] <gary_poster> so you are going to see if it magically fixes itself
[20:11] <gary_poster> ok cool thank you
[20:13] <hatch> yeah the sauce labs videos don't work anymore for whatever reason so I can't see exactly what's going on
[20:13] <hatch> but it looks like the details pane didn't open
[20:19] <hatch> gary_poster: that functionality that you added was really cool though :)
[20:20] <gary_poster> glad you like it hatch :-) .  luca apparently had in mind all along
[20:20] <hatch> I wonder if they can do mockups in something that allows them to be functional
[20:21] <hatch> didn't fireworks used to do that?
[20:21] <hatch> probably needless though :)
[20:22] <hatch> the new iphone sure has some specs...
[20:35] <hatch> ugh phantomjs crashing all the time is really irritating
[20:51] <hatch> hmm huw's branch definitely has something wrong with it
[20:51] <hatch> it's not 'trunk' it's a merge or something
[20:51] <hatch> gary_poster: a re-fire of your branch's CI passed
[20:52] <gary_poster> hatch, 80% good. ;-)  thanks again
[20:52] <hatch> must have been a lag in the host machine or something
[20:52] <hatch> maybe we should be polling on every DOM query in selenium
[20:53] <gary_poster> hatch that sounds interesting...worth a friday card so you don't forget the idea?
[20:55] <hatch> oh looks like we already do that
[20:55] <hatch> wait_for_css_selector
[20:57] <hatch> timeout is 10
[20:57] <hatch> so I'm assuming that's 10s which should be plenty
[23:00] <huwshimi> Morning
[23:02] <hatch> hey huwshimi
[23:02] <hatch> so I took a quick peek at your branch
[23:02] <hatch> and it's not trunk that has the issue
[23:03] <hatch> it appears to be a bad merge between it and your branch
[23:03] <huwshimi> hatch: Oh really? I could reproduce the same thing on a clean trunk
[23:05] <hatch> hmm I couldn't but I could try again
[23:05] <hatch> ok make and test-debug is running, i'll check back in a few and let you know
[23:08] <huwshimi> hatch: It could be an environment issue (strange that that test might just stop working)...
[23:08] <hatch> so it's running the tests now
[23:09] <hatch> well I could reproduce your failure with your branch
[23:09] <hatch> but trunk passed just fine
[23:09] <hatch> yup and trunk passes with flying colours
[23:09] <hatch> so maybe delete your trunk branch and re-branch it
[23:09] <hatch> then try on that
[23:11] <huwshimi> hatch: Hmm... a fresh trunk from today passes just fine...
[23:12] <huwshimi> I'll try a merge into my branch and see what happens
[23:12] <hatch> yeah, and i Merged trunk into your branch - and after resolving the conflicts it still had the same failure
[23:12] <hatch> so there is definitely something off about your branch
[23:12] <hatch> which is why I was thinking it was a bad past merge
[23:12] <hatch> maybe a conflict done wrong or something?
[23:12] <huwshimi> Ah, I'll deal with these conflicts and see what's going on...
[23:15] <hatch> if you need some help ping me, I'll likely be around
[23:21] <huwshimi> hatch: Yeah, seeing the same thing...
[23:33] <huwshimi> hatch: Was there a reason you thought a bad merge might have broken it? I did touch the status bar, but not sure what I could have done to break that specific test...
[23:34] <hatch> huwshimi: sorry no, just a twag
[23:45] <hatch> huwshimi: so what that test failure is saying is that the width was never set
[23:51] <hatch> huwshimi: ok I found your bug
[23:52] <huwshimi> hatch: Well, I think I've fixed it, but only if the test was only passing due to the default resize flag being set to true
[23:52] <hatch> no it was working because of the node.attr being set that you removed
[23:53] <hatch> so the width and height were never being set
[23:53] <hatch> which if I remember was required for IE support
[23:53] <huwshimi> hatch: Right, but if you set resize: false the test would have failed...
[23:53] <hatch> yeah
[23:53] <hatch> as it should I think
[23:53] <hatch> I am pretty sure that width is required....
[23:54] <huwshimi> hatch: Oh well, either way it's fixed :)
[23:55] <hatch> tested in IE?
[23:55] <hatch> I think that's what the width was for
[23:56] <huwshimi> hatch: I'll double check (It was working fine in IE when I QAd it without the width being set).
[23:56] <hatch> oh ok
[23:57] <hatch> I guess if it's not required then you can just delete that from the test :D
[23:57] <huwshimi> hatch: Well, the difference being that when it's used we never call it without calling update() unlike this test...
[23:58] <hatch> ahh
[23:59] <huwshimi> (and hence this test only passing previously because of the default resize value)
[23:59] <hatch> ohh right right