[12:45] <gary_poster> ...longer saucy upgrade than usual, and I still need to find something to remove...
[12:45] <gary_poster> from the hard drive 
[13:10] <gary_poster> need to restart yet again
[13:12] <rick_h_> benji: any idea if there's a way to sync/ignore u'key': u'value' and 'key': 'value' in the charmworld tests for an assertEqual?
[13:13] <benji> rick_h_: I would have thought the unicode/str difference wouldn't cause a problem since u'foo' == 'foo'
[13:13] <rick_h_> benji: nvm, it was noise amongst the real issue I had. 
[13:14] <rick_h_> one line is diff but 50 are shown as ? diff
[13:14] <benji> yeah, the diffs are generated from the repr, so you get a lot of noise;  those differs really should be improved
[13:18] <rick_h_> benji: review if you get any time please? https://code.launchpad.net/~rharding/charmworld/bundle-metadata2/+merge/189406 
[13:19] <benji> rick_h_: sure
[13:20] <rick_h_> thanks!
[13:57] <benji> rick_h_: I'm done with https://code.launchpad.net/~rharding/charmworld/bundle-metadata2/+merge/189406; looks good.
[13:57] <hatch> morning
[13:57] <benji> good morning
[13:57] <rick_h_> thanks benji! appreciate making through it
[13:57] <hatch> how was your weekend?
[13:58] <rick_h_> hatch: your little village made the sports illustrated news :)
[13:58] <hatch> yeah? Well we are awesome...so duh!
[13:58] <hatch> link?
[13:59] <hatch> :P
[14:23] <rick_h_> benji: ooh thanks. Good catch on the extra test. It misbehaved
[14:24] <benji> cool
[14:28] <frankban> gary_poster: shelltoolbox does not seem to be in precise
[14:28] <rick_h_> encouragement for https://pypi.python.org/pypi?%3Aaction=search&term=shelltoolbox&submit=search to get fixed?
[14:30] <frankban> gary_poster: it's in universe starting from quantal -> https://launchpad.net/ubuntu/+source/python-shelltoolbox
[14:31] <frankban> gary_poster: so one option is to include the shelltoolbox file in the charm (as we did for charm tools)
[14:32] <gary_poster> frankban, +1
[14:33] <frankban> gary_poster: cool thanks
[14:33] <hatch> pretty soon our charm will be 100MB with all the includes :D
[14:33] <frankban> brace yourself: huge branch is coming :-(
[14:33] <rick_h_> data centers have fast networks :P
[14:34] <frankban> hatch: a 600 lines python files will not make the difference
[14:35] <hatch> frankban: maybe that 600th line is what breaks the camels back
[14:35] <hatch> takes the whole center down
[14:35] <frankban> hatch: so let's do it!
[14:35] <hatch> lol
[14:39] <rick_h_> abentley: ping, around? CI is failing with failed ssh connections? 
[14:39] <rick_h_> abentley: pm'd url
[14:40] <abentley> rick_h_: Yes, around.
[14:40] <abentley> rick_h_: Looking.
[14:53] <hatch> My internet must have had a rough weekend
[14:53] <gary_poster> Makyo, hey.  We have a service deployment layout issue on comingsoon.  To dupe, deploy mediawiki with DnD, then deploy mysql with DnD, then click the build relation button on mysql to connect with mediawiki.  I see a link going from nowhere to mediawiki, and when I click on mysql, it jumps to the relationship's location
[14:53] <hatch> I think I've been reset to Dialup
[14:53] <gary_poster> Makyo, could you take a look please?
[14:53] <Makyo> Sure
[14:54] <gary_poster> thank you
[14:57] <Makyo> Alright, I see where it is.  Will get in a sec.
[14:58] <gary_poster> awesome thanks
[15:17] <hatch> note to self: if you call a 'reject' promise handler it sets the promise to rejected internally
[15:17] <hatch> weird!
[15:23] <hatch> morning bcsaller
[15:28]  * benji watches rick_h_ vs. Jenkins cage match.
[15:29] <hatch> oh awesome - is it on PPV?
[15:29] <rick_h_> benji: it was a 10 round knock-out!
[15:29] <benji> :
[15:30] <hatch> rick_h_: so you lost?
[15:30] <hatch> :P
[15:30] <benji> oops, I forgot my mouth
[15:30] <benji> :)
[15:30] <rick_h_> hah, well the old rule of "if at first you branch doesn't land...hit retry over and over"
[15:30] <benji> I'm glad I'm not the only one that fights with CI bots.
[15:32] <hatch> rick_h_: so is the ssh connection issue fixed?
[15:32] <rick_h_> hatch: so he added a delay that will hopefuly make it happen less? but this is only on the charmworld lander bits. I don't think this effects the gui stuff (but could be wrong)
[15:33] <hatch> pooeey
[15:39] <rick_h_> hatch: so heads up, my branch hit staging http://staging.jujucharms.com/api/3/bundle/~bac/wiki/3/wiki now will return the list of files (does it have an icon or not, where is the readme, etc) and the charm details for each charm in the bundle
[15:39] <rick_h_> hatch: so this should unblock anything else needed for the bundle view from the charmworld end except the icons on the token which is my next branch. 
[15:39] <rick_h_> hatch: so look for the charm_metadata and files keys. There's logic for locating the readme and such in the charm code. 
[15:40]  * rick_h_ adds a card to update the api docs
[15:41] <hatch> kewlio
[15:41] <frankban> gary_poster: filed bug 1236427 : the kanban does not let me add cards
[15:41] <_mup_> Bug #1236427: Scale up input stops working after units are added/removed <juju-gui:Triaged> <https://launchpad.net/bugs/1236427>
[15:44] <hatch> gary_poster: here is the rework of your branch https://codereview.appspot.com/14454049/ I think we were both on the same page :)
[15:50] <Makyo> jujugui call in 10
[15:50] <gary_poster> jujugui call in 10?  Did I make it?
[15:51] <rick_h_> heh, almost
[15:51] <gary_poster> hatch I'm reviewing your branch fwiw
[15:53] <hatch> chained promises are so hard to read :/
[15:54] <hatch> there has to be a better way!
[15:54] <rick_h_> but but promises are like unicorns flying out of your butt!
[15:54] <rick_h_> magical!
[15:54] <frankban> also filed bug 1236435 
[15:54] <hatch> lol
[15:54] <_mup_> Bug #1236435: The unit detail view does not disappear whe the unit is removed <juju-gui:Triaged> <https://launchpad.net/bugs/1236435>
[15:55] <rick_h_> didn't we have a bug for that frankban?
[15:55] <hatch> rick_h_: nope, s/unit/service
[15:55] <hatch> that's what the bug was for
[15:55] <rick_h_> hatch: oh, my bad
[15:55] <frankban> rick_h_: it si possible, I did not find one
[15:56] <rick_h_> hatch: at least I knew it sounded familiar
[15:56] <hatch> haha yeah - when you said that I had to take a second look :)
[15:56] <frankban> oh, ok
[15:58] <gary_poster> jujugui call in 2
[15:58] <hatch> frankban: so does your branch speed up the charm install a bit?
[15:59] <frankban> hatch: I suppose it does
[15:59] <hatch> nice :)
[16:30] <rick_h_> hatch: got a sec?
[16:32] <hatch> yup
[16:56] <hatch> gary_poster: after a discussion with rick_h_ I'm going to refactor the bundle detail view code to make it easier to test
[16:57] <gary_poster> cool hatch
[17:01] <gary_poster> frankban, "Wow!  Great tests, and very nice improvement.  Code LGTM.  I will check with Rick as to which of us will QA."
[17:02] <frankban> gary_poster: great thanks!
[17:02] <gary_poster> rick_h_, are you doing frankban's QA, or shall I?  Happy to do it if you have not started
[17:02] <rick_h_> gary_poster: qa running right now
[17:02] <gary_poster> awesome rick_h_ thanks
[17:02] <frankban> gary_poster, rick_h_: if you are qaing using juju-core trunk, remember to boostrap with --debug
[17:02] <rick_h_> just took a timeout while it was loading when I saw something about a fakebackend and got confused and bugged hatch 
[17:02] <gary_poster> frankban, had a few trivials, but tests were really awesome
[17:02] <rick_h_> frankban: oh, didn't do --debug 
[17:03] <frankban> rick_h_: yeah, sorry, I had to mention it in the qa instructions. that's a new juju-core thing
[17:03] <rick_h_> ok, do you know what version? is that just trunk? /me is on 1.15
[17:04] <rick_h_> so not the release that went out end of last week
[17:04] <gary_poster> hatch, looks like CI is showing real IE bugs now :-/
[17:04] <frankban> rick_h_: yeah so you need it I think, there was an email in juju explaining the new debug options
[17:04] <gary_poster> I will investigate
[17:04] <rick_h_> frankban: k, thanks for the heads up
[17:07] <hatch> gary_poster: nice catch
[17:07] <hatch> looks like it was Makyo's branch?
[17:07] <Makyo> Perhaps the one that's being proposed right now will fix.
[17:08]  * Makyo fingercrosses.
[17:08] <hatch> great
[17:09] <hatch> it might not have been your branch but that's as far back as I can see right now on sauce labs for some reason
[17:10] <Makyo> Speaking of... https://codereview.appspot.com/14499043 jujugui / gary_poster (since you know how to dupe)
[17:10] <gary_poster> Makyo, ack on it
[17:15] <rick_h_> frankban: qa ok. I ended up just ssh'ing into the machine to verify vs watching the debug logs
[17:16] <rick_h_> frankban: if that's not suffecient or anything let me know and I'll destroy/rebootstrap and go through it again
[17:21] <gary_poster> Makyo, code looks good, but one issue so far: I reverted your changes to service.js and ran the test suite and the new test you added still passed.  The test doesn't actually test the regression, it seems?  Trying qa now.
[17:22] <Makyo> gary_poster, oh, hm, will check, then.
[17:22] <gary_poster> thanks
[17:25] <gary_poster> Makyo, qa is good, though
[17:25] <benji> juju-gui: I have a charmworld review up: https://code.launchpad.net/~benji/charmworld/check-out-and-update-specific-revisions/+merge/189672
[17:27] <rick_h_> benji: will look at it in once lunch comes off the stove 
[17:27] <gary_poster> benji, if you don't get a bite from a more qualified reviewer, ping me.  Branch seems straightforward enough on the face of it
[17:27] <gary_poster> oh, you got a bite :-(
[17:28] <gary_poster> :-) I mean
[17:28] <rick_h_> wait what...me jumps the hook :P
[17:28] <gary_poster> lol
[17:28] <rick_h_> "the big one that got away" 
[17:28] <gary_poster> you are more qualified
[17:28] <rick_h_> or I'll just look at it in a sec
[17:28] <rick_h_> :)
[17:28] <gary_poster> :-) thanks
[17:28]  * gary_poster continues to download win 8.1...
[17:36] <frankban> rick_h_: your QA is fine, thank you!
[17:51] <rick_h_> benji: feedback inbound
[17:51] <benji> cool
[18:14] <hatch> rick_h_: refactored version https://codereview.appspot.com/14454050/ review plz
[18:15] <rick_h_> hatch: looking
[18:21] <rick_h_> hatch: back at ya
[18:25] <rick_h_> benji: so is there a known 'if you run tests this way it'll empty your main db' use around?
[18:25] <rick_h_> benji: somehow in getting my last branch up for review I seemed to have emptied mongo db and need to reingest now to test out the next branch
[18:25] <hatch> rick_h_: thanks, replied, fixed, submitting
[18:27] <rick_h_> hatch: cool thanks. All good, I guess I have a mental block that promise == async and I try to avoid unavoidable async for testing if possible. 
[18:27] <rick_h_> hatch: but the way it's wired it wont' really be async in use so the promise is ok to leave there
[18:30] <hatch> yeah - I love chaining promises
[18:30]  * rick_h_ hates chains :PO
[18:30] <hatch> although I really wish I didn't have to call .bind()
[18:30] <rick_h_> :P that is
[18:34] <abentley> bac, benji or orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/apt-add-repository/+merge/189683 ?
[18:40] <jcsackett> abentley: looking.
[18:41] <jcsackett> abentley: looks good to me.
[18:43] <abentley> jcsackett: thanks.  The trouble with testing for flaws in "make sysdeps" is... you find bugs in "make sysdeps".  This will allow me to remove a workaround.
[18:47] <jcsackett> abentley: yeah, it seems wise to me. the base lxc i clone for development already has python-software-properties in it, so this didn't bug me, but it's definitely good to have it in place.
[18:48] <abentley> jcsackett: Oh, doh!  I forgot --yes.
[18:48] <jcsackett> oh, sure. we can't have make require user input.
[18:48] <jcsackett> i always forget --yes is even a flag.
[19:03] <gary_poster> Makyo, duping deployment layout in a bug is a pain?
[19:04] <Makyo> gary_poster, I don't know what this test is even doing :P  
[19:05] <gary_poster> Makyo, :-/
[19:05] <Makyo> With the old code, it should be winding up in new_services, and it does in the browser, but not in the test.
[19:05] <Makyo> Trying a whole new delta for now.
[19:06] <gary_poster> k
[19:13] <rick_h_> benji: last one for the day if you've got the bandwidth. Smaller/easier one. https://code.launchpad.net/~rharding/charmworld/bundle-metadata3/+merge/189691
[19:13] <Makyo> Gah, testing the wrong thing, should have it in a few.
[19:14] <benji> rick_h_: yeah, I can take a look
[19:14] <rick_h_> benji: added quick QA note
[19:14] <benji> k
[19:25] <rick_h_> gary_poster: from here I'm going to pick up the bundle icon urls/helpers so that we've got pretty icons as the next step is making a pretty demo workable. 
[19:25] <rick_h_> gary_poster: any other first step you had preferred first?
[19:25] <gary_poster> rick_h_, perfect, thanks
[19:25] <rick_h_> k, cool
[19:47] <hatch> Makyo: did your branch land? CI is still failing
[19:47] <hatch> so just curious
[19:47] <Makyo> hatch, not yet.
[19:47] <hatch> oh ok np
[19:47] <Makyo> lbox WHY ARE YOU FAILING
[19:48] <hatch> mohohahaha
[19:48] <lbox> NO PASS FOR YOU
[19:48]  * Makyo kicks lbox 
[19:48] <hatch> lol
[19:54] <Makyo> gary_poster, quick +1 on the test change? https://codereview.appspot.com/14499043/diff/5001/test/test_environment_view.js
[19:55] <benji> rick_h_: I forgot to mention it in the review, but QA looked good.
[19:55] <rick_h_> benji: cool, thanks for the review
[19:58] <rick_h_> ok, landing that. Unblocks almost all of the bundle details and bundle token now for the Gui. I'm outta here. 
[19:59] <hatch> ugh WidgetParent/Child is such a horrible designe
[19:59] <hatch> design even
[20:00] <gary_poster> Makyo, +1, thanks!
[20:01] <gary_poster> thanks rick_h_ 
[20:06] <rick_h_> hatch: only real issue is it's pretty invisible unless you know it's there. 
[20:06] <hatch> yeah that's what I mean - there is no way to 'follow' the code
[20:06] <rick_h_> only used it in once place color me curious why it's rubbing you wrong. 
[20:07] <hatch> I was raised to hate it
[20:07] <hatch> it's not my fault
[20:07] <rick_h_> lol
[20:07] <hatch> blame society
[20:07] <hatch> haha
[20:08] <rick_h_> ok, I'll send you a sympathy card later for it :P
[20:08] <hatch> lol
[20:16] <hatch> rick_h_: FYI BrowserSearchView is not a view
[20:16] <hatch> :P
[20:17] <gary_poster> deployment (sandbox?) actually successfully shows deployment 1 time out of 4 for me :-(
[20:17] <hatch> rick_h_:  FYI so kidding btw
[20:25] <gary_poster> hatch if you are curious, only one test failure in IE and looks fairly benign.  looking a bit more
[20:25] <hatch> ok thanks
[20:25] <hatch> gary_poster: Makyo said his branch might fix the failure
[20:25] <hatch> just FYI
[20:26] <gary_poster> hatch, running with that branch.  I think he might have fixed failures, because the only one I see is in test_models.js
[20:26] <gary_poster> (actually running with trunk: he landed)
[20:26] <Makyo> Might maybe could perhaps inshallah..
[20:27] <Makyo> I'll start up IEVM
[20:27] <hatch> ohh ok ok
[20:32] <rick_h_> hatch: :P well you guys all get fits when I say the word "widget" :P
[20:33] <hatch> WIDGET!!!!!!!!!!!!
[20:34]  * rick_h_ waits for the irc channel to explode
[20:34] <rick_h_> we'll need to get a new one
[20:35] <gary_poster> heh
[20:35] <hatch> gary_poster: those relation errors in the new topo code...is someone working on them? I'm just worried they are causing cascading failures
[20:36] <gary_poster> hatch, this is what bcsaller is working on.  they are happening because the position annotations are not there
[20:36] <hatch> ohh ok cool cool
[20:36] <bcsaller> hatch: if the positions are set it does work fine
[20:37] <hatch> oh ok cool, so it's benji's fault
[20:37] <hatch> :P
[20:37]  * hatch keeps pushing the blame
[20:37] <gary_poster> hatch, heh, no, he tried to set the annotations but they are not being kept
[20:37] <hatch> ohh fine!
[20:37] <hatch> :)
[20:38] <hatch> clicking on a bundle works now here
[20:38] <hatch> pretty cool
[20:38] <hatch> but really need to implement the bundle caching
[20:40] <gary_poster> heh, hatch, Makyo the one test is failing because my vm's system clock thinks that we are in May :-P
[20:41] <Makyo> May, October, they're like the same thing.
[20:41] <gary_poster> so CI is hosed but IE, at least on my vm, is AOK
[20:41] <gary_poster> :-)
[20:41] <hatch> lol bad Makyo bad Makyo writing a test which relies on a Date object :P
[20:41] <Makyo> I did NO SUCH THING.
[20:41] <gary_poster> hatch, it is a charm test from ages ago :-P0
[20:41]  * Makyo whew <.<
[20:41] <gary_poster> heh
[20:42] <hatch> lol - actually, in a past life I wrote a test which relied on a date...the only time it failed was when we brought on an international developer who coudln't get the tests to pass on her machine lol
[20:43] <hatch> international being - cross the date line
[20:43] <rick_h_> hatch: you mean huw. He got bit by that. Couldn't land because the date was off for AU 
[20:43] <rick_h_> too many timezones away
[20:43] <hatch> crap I've done it twice?
[20:43] <hatch> oh bpy
[20:43] <hatch> boy
[20:44] <hatch> oh wait
[20:44] <hatch> no I fixed huw's failure
[20:44] <hatch> I caused the other one
[20:44] <hatch> lol
[20:45] <hatch> rick_h_: when is your EOD?
[20:45] <rick_h_> hatch: 45min ago
[20:45] <rick_h_> just checking something now that I'm back from day care
[20:46] <rick_h_> hatch: why, what's up?
[20:46] <hatch> just proposing the 'bundle token click' branch
[20:46] <hatch> would like to get it landed
[20:46] <hatch> it's a super trivial diff
[20:46] <rick_h_> hatch: k, ping when it's up and I'll try to peek between stuff
[20:46] <rick_h_> hatch: yea, should be tiny 
[20:46] <hatch> will do thx
[20:52] <hatch> rick_h_: sorry chunk missmatch https://codereview.appspot.com/14518043/
[20:52] <hatch> but diff is really small :)
[20:52] <hatch> gary_poster: I'll work on bundle icons now?
[20:53] <gary_poster> hatch looking
[20:53] <gary_poster> hatch I think that is blocked on Rick's work
[20:53] <hatch> his landed AIUI
[20:53] <hatch> I'll check the api
[20:54] <gary_poster> hatch, one landed today, but his active card is what you need ("charmworld can redirect from charm ids or branches to icons and support default bundle icon")
[20:54] <hatch> ohh right yes
[20:54] <hatch> alright then I'm open to whatever
[20:55] <gary_poster> hatch, suggest "hook up and style tabs on detail view"
[20:55] <gary_poster> hatch that then opens up README and source tab tasks after that
[20:55] <gary_poster> hatch, you can push tab styling to Huw, of course; just needs to be done
[20:55] <hatch> sounds like a plan
[20:57] <gary_poster> bcsaller, when you get through your current mystery, another to explore is that dragging a bundle token to deploy works one out of 4 times for me--and sometimes it has worked in the fakebackend but not in the gui itself.  I'm duping on comingsoon
[20:57] <gary_poster> you drag once and nothing happens, then drag again and fakebackend complains that service already exists
[20:58] <hatch> when I do the DD it locks up myu machine firing off google analytics calls
[20:58] <hatch> locks the tab that is
[20:58] <gary_poster> oh nice
[20:58] <gary_poster> hatch reviewing your branch...
[20:58] <hatch> cool thanks,
[20:58] <hatch> it's very trivial
[20:59] <gary_poster> all tthe more reason to ship it :-)
[21:01] <hatch> consider it shipping!
[21:05] <hatch> oh I love it when the utilities ppl do a meter reading and your next bill is lower
[21:10] <rick_h_> hatch: so that's the charm icons in a bundle
[21:10] <rick_h_> that's unblocked
[21:10] <rick_h_> the bundle icon itself is blocked on next branch
[21:13] <rick_h_> and catching up the readme/tabview stuff is unblocked so coolio
[21:20] <gary_poster> rick_h_, oh, there's the API to get an icon from alp branch now?
[21:20] <gary_poster> alp == an lp
[21:20] <rick_h_> gary_poster: no, but the icons on the charm token for the charms inside can be done now
[21:20] <rick_h_> the little ones on the bottom of the token
[21:20] <gary_poster> oh cool, I misunderstood what we needed then
[21:20] <gary_poster> great
[21:20] <rick_h_> the bundle icon work is now on deck
[21:21] <gary_poster> gotcha
[21:21] <rick_h_> that should be the last thing related to UX from charmworld (other than related bundles?) 
[21:33] <gary_poster> rick_h_, fwiw we can hold off on bundle icon.  we don't need that to be successful.  If you haen't started, I suggest starting icon hookup in token and details.  I worry that we will need to show what charms are recommended
[21:34] <gary_poster> sorry, thought that was what we were doing
[21:34] <gary_poster> if you have started, np
[21:34] <gary_poster> finish it :-)
[21:40] <gary_poster> rick_h_, "I worry that we will need to show what charms are recommended" : in the charmworld output
[21:51] <rick_h_> gary_poster: yea, was going to do them at the same time. I realize now why it's confusing
[21:51] <rick_h_> one is 'charm icon given bundle data' and the other is the 'bundle icon itself'
[21:52] <rick_h_> gary_poster: so the full charm details (including recommended) is available in the interesting/search results view and the only tiny icons to show in a bundle token will be recommended charms
[21:52] <rick_h_> so I'm not sure what the ""I worry that we will need to show what charms are recommended" is?
[22:06] <huwshimi> Morning
[22:06] <rick_h_> morning huwshimi 
[22:30] <hatch> morning huwshimi
[22:34] <rick_h_> I always want to ask huwshimi "so how's Tues looking? I want to plan ahead for tomorrow"
[22:35] <hatch> I do all the time
[22:35] <hatch> he is probably getting irritated
[22:35] <hatch> :)
[22:41] <hatch> rick_h_: still around?
[22:42] <rick_h_> hatch: yes
[22:42] <huwshimi> rick_h_, hatch: It is a beautiful spring morning
[22:42] <hatch> ok real quick...
[22:43] <rick_h_> heh, lovely fall blustery day. 
[22:43] <hatch> in _dispatchTabEvents() you(or someone) use the tab contents to decide what to do next....why didn't you/others use the label content instead?
[22:43] <hatch> it seems way less fragile
[22:43] <rick_h_> hatch: because the labels don't change if you've already loaded the content
[22:43] <rick_h_> hatch: but the content will change
[22:44] <rick_h_> hatch: so it's a build in "don't load this twice" mechanism
[22:44] <rick_h_> hatch: and not dependant on sync'ing some state tracked somewhere. 
[22:44] <hatch> ohh, hmm
[22:44] <hatch> I always wondered why there was that flash of text
[22:44] <hatch> heh
[22:44] <hatch> can I fix it to use a state tracker?
[22:44] <hatch> mainly to get rid of that flash of text
[22:45] <rick_h_> Off the top of my head not sure, I'd have to look. Which tab is this that flashes? 
[22:45] <hatch> features, readme, and....
[22:46] <rick_h_> ah, it's because the spinner doesn't properly lay over it. I guess I've jut not realized it. 
[22:46] <rick_h_> hatch: I think a shorter path would be to make it hidden by default and then show on load? but then there's the spinner to deal with. It was always meant ot be fixed so the spinner was sized better and overlays things so you'd not see it
[22:46] <rick_h_> hatch: but whatever floats your boat/you can get working. 
[22:47] <rick_h_> hatch: the general idea was that it was built in dupe detection and I think we needed some content in there by default for the spinner to glom onto 
[22:47] <hatch> ok I'll investigate
[22:47] <hatch> thanks
[22:47] <hatch> I figured there had to be a logical reason
[22:47] <hatch> heh
[22:47] <rick_h_> yea, I think we never fixed it because we always thought the spinner/activity thing would fix it
[22:47] <rick_h_> but never got around to that
[22:48] <hatch> wish there was a built in load-on-visible method in tabview
[22:48] <rick_h_> man, now that you point that out it's so awful /me is ashamed. 
[22:48] <hatch> so many of these yui modules seem to have been left to rot
[22:49] <hatch> lol
[22:49] <rick_h_> hatch: well we do use our own tabview widget that doesn't do much but extend the YUI one. 
[22:49] <rick_h_> hatch: so there's a place to hack something in to use
[22:49] <hatch> oh yeah for sure - but I don't want to deal with that now hah
[22:49] <rick_h_> hatch: but then again we've got plans to animate/slider things so I'd not worry too much about it atm since it'll change
[22:49] <hatch> ahh right right
[22:49] <rick_h_> hatch: so honestly, I'd leave it be for now and move forward and chalk it all up to UX cleanup already planned 
[22:50] <hatch> ahh I love that promise code
[22:50] <hatch> it just makes that render method so clean to read :)
[22:51] <rick_h_> I think all tabs go through the dispatchTabEvents call so there is a single place to track state. Originally we didn't have that and I think tracking if a tab was loaded or not was a pita
[22:51] <rick_h_> even tabs that don't need to do anything, just show
[22:52] <hatch> right
[22:52] <hatch> another irritant with tabview - the id's
[22:52] <hatch> seriously...
[22:52] <hatch> it 'requires' ids
[22:52] <hatch> oy
[22:53] <hatch> I know it's for progressive enhancement
[22:53] <hatch> but....
[22:53] <hatch> c'mon
[22:53]  * hatch is having a bad day I guess lol
[22:53] <rick_h_> yea, I mean it's not all our fault :P
[22:53] <hatch> haha yeah I know
[22:53] <hatch> I added a note to remove the reference to the id
[22:53] <hatch> then I was like....oh...right
[22:54] <rick_h_> heh, nope
[22:54] <rick_h_> which actually messes us up with the tabs on both inspector/not
[22:54] <rick_h_> which we really need to make sure only one shows at a time anyway
[22:55] <hatch> yeah true true
[22:56] <hatch> so itunes is supposed to download my podcasts to my NAS - but if it can't connect, it downloads them to my local drive :/
[22:56] <rick_h_> hatch: what about setting the content to "" right after we do the check, then launch the remote call
[22:56] <hatch> oh i've already changed it to trigger off of the label
[22:56] <rick_h_> at least the flicker will be really really short and maybe not noticeable since we won't wait to remove the default text until it comes back
[22:56] <rick_h_> heh
[22:57] <rick_h_> and it won't load twice?
[22:57] <hatch> nope because of the state object
[22:58] <rick_h_> ok, cool then. I'm out
[22:58] <hatch> have a good one
[22:58] <hatch> I'll propose and you can review it in the morning
[23:33] <hatch> rick_h_: if you return - trying to load the README file but the endpoing "/api/3/charm/~benji/wiki/5/wiki/file/README" is 404ing
[23:35] <hatch> rick_h_: ignore that - I am an idiot
[23:41]  * benji senses a severe lack of file extensions in the force.
[23:43] <hatch> I wish the charm/bundle models had a 'type' attribute
[23:43] <hatch> would really clean up a lot of this code haha
[23:43] <hatch> is there a reason why we don't?
[23:44] <hatch> well I'm adding one now
[23:54] <rick_h_> hatch: no, it should be added
[23:54] <hatch> kewl - it's added
[23:54] <rick_h_> hatch: that way they can share the rest of hte logic together. The only thing that's diff is the id
[23:54] <rick_h_> benji: yea, the lack of extensions bugs me, but it's supported
[23:55] <hatch> rick_h_: so i've added the tabview and readme but I need to write tests now so it won't be done today as it's already 1h past EOD
[23:55] <benji> hatch: wouldn't a type check work?
[23:55] <rick_h_> so there's logic to lowercase the list of files, and search for anything that starts with 'readme' and work with it
[23:55] <rick_h_> benji: yea, that too since they're diff models 
[23:55] <rick_h_> hatch: all good, will peek when you're ready
[23:56] <hatch> I don't want to rely on some crude 'does this attribute' exist check
[23:56] <hatch> so they now have an entityType attribute
[23:56] <hatch> which is either 'charm' or 'bundle'
[23:56] <rick_h_> hatch: well if you do that make sure you're checking the doctype in the api
[23:56] <rick_h_> hatch: because that's the supplier of the info
[23:56] <hatch> it doesn't matter
[23:56] <rick_h_> hatch: and should be sync'd 
[23:56] <hatch> If you're creating a Charm Y.Model instance, it's a charm
[23:56] <rick_h_> right, but it should. if charmworld changes it, the gui should just roll with it
[23:56] <hatch> if you're creating a Bundle Y.Model isntance, it's a bundle
[23:57] <hatch> or are you implying that we are merging the two models?
[23:57] <rick_h_> hatch: meh, true I guess. and the doctype is outside the data passed to create a new model instance :/
[23:57] <rick_h_> hatch: well, what I mean is that http://staging.jujucharms.com/api/3/search?text=wiki supplies a doctype
[23:58] <rick_h_> hatch: and a lot of code (locating the readme) can be matched between the two
[23:58] <rick_h_> hatch: but I'm just speaking out loud, not out of something we need atm so ignore me. 
[23:59] <rick_h_> I guess wherever json -> models it should be listening to the doctype
[23:59] <rick_h_> to create the right instance, and we could really have a model list that's either a charm or a bundle
[23:59] <rick_h_> I've not looked at how that's been done so I can't speak to it atm.