[00:00] <huwshimi> hatch: Any idea what is going on here? http://ci.jujugui.org:8080/job/juju-gui-merge/575/console
[00:01] <hatch> just re-run it
[00:01] <huwshimi> ok
[00:01] <hatch> assuming you have the conflicts fixed
[00:01] <huwshimi> yeah
[03:14] <hatch> huwshimi looks like thse 2 landed well
[03:18] <huwshimi> hatch: Yeah, I had to fix the tests and merge conflicts for both. I was prepared for that as all my branches are touching the same code
[03:18] <hatch> ahh - well this mv is coming together quite nicely
[03:19] <hatch> I found a really simple way to do the new inspector tests heh
[03:19] <hatch> well a simple way to conver it
[03:19] <huwshimi> Ah nice!
[03:20] <hatch> yeah I'll put it up tomorrow
[03:20] <huwshimi> Great
[03:20] <hatch> now the card I've been working on is going to be quite interesting...
[03:21] <hatch> the one where we delete the machine token before the delta comes in
[03:26] <huwshimi> hatch: oh yeah, it'll be a nice change, but tricky to handle
[03:29] <huwshimi> hatch: Any ideas how you'll do it?
[03:31] <hatch> heh still investigating....it's probably going to be a multi step process, the model will be updated with the appropriate data when juju sends it's ACK but then when the detla comes in, it swaps it then...
[03:36] <hatch> well I'm out, have a good day
[10:39] <rick_h__> morning party people
[10:42] <urulama> rick_h__: morning
[10:55] <frankban> rick_h__: morning
[10:55]  * frankban lunches
[11:46]  * urulama lunches
[12:16] <bac> ahoy
[12:18] <rick_h__> welcome back bac
[12:19] <bac> you too, though a day late
[12:23] <rick_h__> bac: spent 3hrs watching youtube videos on landscape photography for my yosemite trip
[12:24] <rick_h__> bac: watch out, here comes hdr I think, I don't have all the ND filter extra 10lbs of stuff on my lens gear :/
[12:24] <bac> fun
[12:24] <bac> we took a day trip on friday and i took some crap fotos, but it was fun
[12:27] <rick_h__> party
[12:29]  * urulama checks bac.photo ... no Yosemite :(
[12:57] <bac> jujugui: just had failures bootstrapping to ec2:us-west-2.  changed to us-east-1 and all was good.  ymmv.
[12:58] <bac> urulama: never been to yosemite.  :(
[14:20] <frankban> urulama, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/75 (charmstore/golang). anyone available? thanks!
[14:21] <urulama> frankban: be on it in 5min
[14:21] <frankban> urulama: thanks
[14:35] <hatch> jujugui need one more review on huws branch https://github.com/juju/juju-gui/pull/500
[14:37] <urulama_> hatch: internal server error ...
[14:37] <hatch> hah hah haaaaaa
[14:37] <rick_h__> hatch: looking
[14:42] <hatch> thx
[14:50] <hatch> jujugui call in 10
[14:57] <hatch> jujugui call in 2
[15:01] <rick_h__> jujugui call time antdillon urulama_ ^
[15:01]  * bac trying...
[15:02]  * bac reboots
[15:11] <hatch> Makyo:  https://github.com/juju/juju-gui/pull/501
[15:11] <Makyo> Thanks
[15:11] <hatch> really trivial, heh
[15:14] <hatch> jrwren: so they don't have overnight camp there? 
[15:15] <hatch> or do I have a different idea of camp :)
[15:15] <jrwren> hatch: she is a little young for that. She would probably be fine.
[15:15] <jrwren> hatch: no kids eh?
[15:15] <jrwren> hatch: once kids get to elementary school, instead of going to day care all day in the summer, they go to day camps.
[15:15] <jrwren> hatch: a lot of our kids friends are at day camp all day every day of all of summer vacation.
[15:16] <rick_h__> luca: ! the guys brought up something important
[15:16] <jrwren> hatch: it makes for a very different childhood than I had. 
[15:16] <rick_h__> luca: how does one delete a unit on a machine/container?
[15:16] <hatch> jrwren:  nope no kids, one big d.i.n.k, here
[15:16] <hatch> ahh yeah we don't have day camps, just day care for summer
[15:16] <jrwren> hatch: stop, you'll make me jealous.
[15:16] <hatch> although I was different because I went to the lake for most of the summer
[15:16] <hatch> lol
[15:17] <luca> rick_h__: each unit has a destroy button found in a more menu
[15:17] <rick_h__> luca: ok, /me goes to look for that screenshot
[15:17] <rick_h__> luca: and anything on the inspector list for the units?
[15:17] <hatch> day camps actually sounds like a really great idea
[15:17] <luca> rick_h__: https://drive.google.com/file/d/0B7XG_QBXNwY1RXozODVyeU5QMUU/edit?usp=sharing
[15:18] <luca> rick_h__: thats right, at the moment scaling down can only be done manually
[15:19] <rick_h__> luca: that's destroy machine, but what about a single unit on that machine?
[15:19] <luca> rick_h__: it’s the same
[15:20] <luca> rick_h__: there should be a more menu associated with every unit available on hover
[15:20] <luca> rick_h__: inside that more menu you can find destrou
[15:20] <luca> rick_h__: destroy^
[15:20] <rick_h__> luca: oh? there's a more menu for every unit in a machine/container?
[15:20]  * rick_h__ missed that
[15:21] <luca> rick_h__: I just check the states file and it’s missing from that…
[15:21] <luca> rick_h__: somewhere down the MV iterations Spencer and I have forgotten to include it in the states file
[15:22] <rick_h__> luca: ok, so we're not completely nuts to not have it 
[15:22] <luca> rick_h__: but we’ve had a destroy button on units since the button
[15:22] <rick_h__> luca: thanks 
[15:22] <luca> rick_h__: no worries
[15:22] <luca> rick_h__: I don’t have Spencer available to make a new mock-up though
[15:22] <luca> rick_h__: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1YjNQajhsMUNHOFE/edit
[15:22] <rick_h__> luca: all good
[15:22] <rick_h__> we can work it out
[15:23] <luca> rick_h__: ok, thanks
[15:23] <rick_h__> anything else in there besides the destroy?
[15:23] <rick_h__> luca: maybe we'd put the web view stuff in there if we get that feature in
[15:23] <luca> rick_h__: I was thinking of “View on the web”
[15:23] <rick_h__> right
[15:23] <luca> rick_h__: yeah
[15:23] <rick_h__> ok cool
[15:23] <luca> rick_h__: we’re in sync :P
[15:23]  * rick_h__ is scared now
[15:23] <luca> rick_h__: lol
[15:42] <kadams54> jujugui: Sorry about missing standup. Lost my internet connection and then my phone tethering failed me, so ended up relocating.
[15:42] <rick_h__> kadams54: all good
[15:42] <rick_h__> kadams54: any notes on your current card?
[15:42] <rick_h__> kadams54: I wasn't sure what 'all classes' meant
[15:43] <kadams54> rick_h__: we need autodeploy functionality now in both the MachineViewPanelView and DeployerBar classes.
[15:43] <rick_h__> kadams54: right, and it's in the MV panel currently?
[15:43] <rick_h__> kadams54: at least the UX is there, /me hasn't tried it out
[15:44] <kadams54> rick_h__: Yup. Got that refactored into a class extension and all tests are passing, but there aren't any unit tests touching those methods specificially.
[15:44] <hatch> frankban:  rick_h__ Makyo was there a reason why we originally went with removing ghost models of machines/containers/units instead of updating them on the delta to begin with? 
[15:44] <kadams54> rick_h__: So I'm writing up some new tests before landing it.
[15:45] <rick_h__> hatch: I can't recall any reason. Just easy? Maybe some connection point issue between the delta coming back?
[15:45] <rick_h__> kadams54: ok awesome thanks
[15:45] <frankban> hatch: I don't remember: does the ghost model share the same id as the real one that will come?
[15:45] <hatch> frankban:  no their id's will be different, but that doesn't necessarily mean we can't update it
[15:46] <hatch> I am just devising a plan and wasn't sure if there was some reason why we didn't do that originally 
[15:46] <urulama_> frankban: been on a call, continue your PR
[15:46] <frankban> hatch: so are you planning to update the models in handlers.js?
[15:46] <rick_h__> hatch: I think the main thing is to make sure we don't couple too much stuff together doing that
[15:47] <hatch> so my plan (still to be determined if this will work) when juju responds with ACK we update the ghost model with the 'real' ids - then when the delta comes in, we search for the id supplied in the detla and update the model accordingly
[15:47] <hatch> right now the issue is that when juju sends the ACK we destroy the ghost model
[15:48] <hatch> so we don't have any UI until the delta comes in
[15:48] <rick_h__> right
[15:48] <kadams54> hatch: what card are you working on?
[15:48] <rick_h__> I think your plan seems sane 
[15:49] <hatch> kadams54:  in Project 1
[15:49] <kadams54> hatch: yeah, this is the uncommitted state not being removed until we get the ACK, right?
[15:49] <frankban> hatch: that would work fine, assuming we have the real id for each call at juju ACK time
[15:49] <hatch> frankban:  right, do you know if that's the case? 
[15:49] <hatch> I am assuming so, but have no data to back that up yet
[15:50] <frankban> hatch: no, we need to check, and it can be done easily by looking at go.js
[15:50] <frankban> hatch: if that's the case, then +1 on your plan
[15:50] <hatch> great thanks all, I'll dig deeper
[15:53] <kadams54> hatch: just a heads up: this may impact the stuff I just landed in the onParentResults handler specified in lazyAddUnits.
[15:55] <hatch> kadams54: it shouldn't, this is all happening in the callback after the juju ACK so it's all one layer up from where that's happening
[15:55] <hatch> onParentResults is called well before this stuff
[15:55] <kadams54> hatch: cool
[15:55]  * rick_h__ runs to get food stuffs
[15:56] <hatch> kadams54:  with that said, your changes makes this work properly though :)
[15:56] <kadams54> yay
[16:06] <hatch> jujugui does anyone have any tricks to working on the gui in a real env? 
[16:07] <frankban> hatch: you know mine, mostly for hacking. if you mean being able to have a branch in the lxc, then no, but I always wanted to investigate something like that
[16:08] <frankban> hatch: anyway, mine is: juju set juju-gui juju-gui-debug=true juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git BRANCHNAME"
[16:08] <hatch> frankban:  well I want to work on the gui in the local env without having to push it up all the time
[16:08] <hatch> frankban:  using juju-gui-debug=true does that allow me to modify the source in the charm and have it reflected in the real env?
[16:09] <frankban> hatch: and then hack on /var/lib/juju-gui/juju-gui/build-debug (or something like that)
[16:09] <hatch> ok I'll try that thanks
[16:16] <hatch> huh it appears that local isnt' working for me, it's not spinning up an lxc instance
[16:16] <hatch> 1.20.1
[16:17] <hatch> hmmmmmmmmm
[16:29] <rick_h__> hatch: any luck?
[16:30] <hatch> rick_h__:  yeah got it deployed, changes in the dir frankban mentioned don't appear to show up though
[16:32] <frankban> hatch: did config-changed complete its execution? are you in the build-debug directory? are you refreshing your browser hard?
[16:35] <hatch> frankban:  yeah I'm on the develop branch, and modifying in the same dir you mentioned
[16:35] <hatch> no amount of refreshes seem to help
[16:36] <frankban> hatch: what's the content of /etc/init/guiserver.conf?
[16:37] <hatch> --guiroot="/var/lib/juju-gui/juju-gui/build-debug" \
[16:37] <hatch> assuming that's the line you're interested
[16:37] <hatch> that's where I'm modifying but nothings changing in the browser....
[16:37] <frankban> hatch: yes, so those are the file served
[16:37] <frankban> being served
[16:39] <frankban> hatch: in var/log/upstart/guiserver.log you should see what files are served for each request
[16:40] <hatch> frankban:  yeah so it turns out it was a really bad cache
[16:41] <hatch> :/ sorry
[16:41] <frankban> hatch: np
[16:41] <hatch> the good news is that the machine view actually creates machines
[16:41] <hatch> :)
[16:42] <frankban> hatch: :-) I supposed that, shouldn't I ?
[16:42] <hatch> haha - you never know :)
[16:42] <hatch> looks like the callbacks are passed the new 'real' ids
[16:42] <hatch> so this will work
[16:43] <hatch> it's only passed the new id though
[16:43] <hatch> but that's enough
[16:46] <hatch> *sigh* one of my thunderbolt ports is loose...apple quality....
[17:52] <marcoceppi> who owns charmworld? is it you guys or is it still sinzui & co>
[17:53] <rick_h__> marcoceppi: it's us still
[17:53] <rick_h__> marcoceppi: what's up?
[17:53] <marcoceppi> rick_h__: nm, just been building a new review queue, doesn't affect you guys much but I'll cc your list as a heads up
[17:53] <rick_h__> marcoceppi: cool thanks. 
[17:54] <rick_h__> marcoceppi: also, we'd love to chat. I'm not sure how much jcastro/arosales told you about our upcoming plans to deprecate charmworld
[17:54] <marcoceppi> I got the low down from you guys last sprint
[17:54] <marcoceppi> which is why I started the new review queue
[17:54] <rick_h__> marcoceppi: so would like to chat with you and tvansteenburgh around a migration path from charmworldlib in the nearish future
[17:54] <rick_h__> marcoceppi: cool
[17:54] <marcoceppi> rick_h__: yeah, that too
[17:55] <rick_h__> marcoceppi: and curious how the review queue stuff is to work in a 'juju publish' world (sans LP)
[17:55] <hatch> oo new review queue nice
[17:56] <marcoceppi> rick_h__: I'm building a login system using Ubuntu/Launchpad SSO, when taht happens you'll just submit a new request for review there and we'll build plugins to map wherethe soruce for that charm is held to monitor merge req
[17:56] <marcoceppi> but it's going to need some thinking/work
[17:56] <marcoceppi> already building in gh support to monitor the mirrors
[17:56] <rick_h__> marcoceppi: yea, that's what we need to sync up on. In a publish world there's no promise of vcs info there
[17:57] <marcoceppi> yeah, now that it's sinking in, I can already see a glaring hole-in-the-head for how we maintain promulgated charms :)
[17:58] <rick_h__> marcoceppi: yea, we want to sync up and solve those issues ahead of the game if possible
[17:59]  * marcoceppi nods
[17:59] <marcoceppi> want to do that sometime this week?
[17:59] <rick_h__> marcoceppi: sounds good, /me checks calendar
[17:59] <rick_h__> marcoceppi: pretty open Tues/Wed or Friday here
[17:59] <marcoceppi> Tues work well for me
[18:00] <rick_h__> marcoceppi: k, added a meeting with you and tim
[18:19] <hatch> rick_h__:  I sent an email to luca and peeps, I forgot to add that I think it should be pre-MV 1.0, thoughts?
[18:20] <rick_h__> hatch: looking
[18:21] <rick_h__> hatch: yea, there's some thoughts on onboarding from back when MV was designed. 
[18:21] <rick_h__> hatch: and it's a known thing they're looking at as the notifications are too transient and we talked about them during the sprint
[18:22] <rick_h__> hatch: so I don't think your email is a surprise or anything. 
[18:22] <hatch> ahh ok good - I was just sitting there, going "umm this change should be instant" heh
[18:22] <rick_h__> hatch: and it's something to get right before launch for sure
[18:22] <hatch> then "oh duh"
[18:38] <hatch> TIL getById uses an internal id map which doesn't get updated in lazy model lists when you update the id in the model and there are no util methods to do so
[18:38] <rick_h__> heh, good lesson to know :)
[18:39] <hatch> looks like I'll have to write a util method to fix that
[18:39] <hatch> time to patch YUI
[18:40] <hatch> I was stepping through the delta stuff going ....umm why is this id not being picked up by getById.... heh
[18:40] <hatch> ok taking lunch bbl
[19:08] <urulama> good night, jujugui, have a great rest of the day
[19:08] <bac> see ya urulama-afk
[19:30] <kadams54> guihelp: need a code review only (no QA) for: https://github.com/juju/juju-gui/pull/503
[19:32] <Makyo> On it.
[19:32] <kadams54> Makyo: thanks!
[19:32] <Makyo> kadams54, mind taking a look at PR 502 in exchange?  It's tiny.
[19:33] <kadams54> Makyo: yeah, will do.
[19:41] <kadams54> Makyo: comment added.
[19:41] <rick_h__> kadams54: looking
[19:44] <Makyo> kadams54, thanks.  We don't have direction on what to do with the add container link, since that will be moving to the more menu soon; once there, we'll have direction on whether to remove or show as disabled.
[19:44] <kadams54> Makyo: yeah, in reviewing the bug, it seemed ambiguous. rick_h__: do you know if the "more" menu is pre- or post-1.0?
[19:45] <Makyo> kadams54, yeah, sorry, forgot to link the bug.
[19:45] <kadams54> If it's post-1.0, it seems like we ought to get clarification.
[19:45] <rick_h__> kadams54: pre
[19:45] <kadams54> Ah good.
[19:45] <rick_h__> kadams54: it's what we got the delay points for
[19:45] <rick_h__> kadams54: the more menu and some other UX enhancements
[19:46] <kadams54> rick_h__: basically the revamped MV design they showed us in London, right?
[19:46] <rick_h__> kadams54: yep
[19:46] <rick_h__> we want to release with the cleaner better UX out of the gate vs waiting to update it
[19:46] <kadams54> Makyo: I'm fine with landing PR#502 then.
[19:47] <kadams54> I'll add a comment to that effect in the PR.
[19:48] <kadams54> Looks like huw's all over the more menus :-)
[19:48] <rick_h__> yea, need to check on their status tonight
[20:08] <hatch> bac:  so I just chatted with the local apple store (not a real apple store) and he said after they run a diagnostic on it, about 2 days to order the new logic board then 2-3h install - so not horrible, maybe you should look into it as well if you're having the same problem
[20:08] <hatch> assuming of course you have a local apple repair shop heh
[20:09] <bac> hatch: did they mention if there was a design change?
[20:09] <hatch> there are reports of people with new machines with the same problem (he wasn't even surprised that this happened) so my guess is no
[20:10] <hatch> guess logic boards are cheap for apple lol
[20:11] <bac> seems like a pita if there is no reason to think it'll really fix the problem
[20:11] <bac> i think your eraser solution is pretty elegant...
[20:12] <hatch> lol - my warranty is up in December so I want to make sure it's fixed before that :)
[20:13] <bac> yeah, mine is long gone
[20:13] <hatch> applecare is really expensive, I wonder how much a logic board costs 
[20:16] <hatch> $379 for 3 years....maybe it's worth it if it costs a lot to fix heh
[20:20] <hatch> logic board from ifixit is almost $1k lol ouch
[20:20] <hatch> I hope that's not the regular price haha
[20:21] <hatch> ohh it's 3 years total, so only an additional 2 years for the extra $379.... almost $200/yr
[20:47] <hatch> jujugui when trying to update an id of a lazy model object and the id already exists, would you expect it to throw? return false? return the object at that id?
[20:47] <hatch> I'm thinking throw....but we don't really throw anywhere else...
[20:47] <hatch> I'm thinking return false or return the new id if it was successful
[20:48] <rick_h__> undefined vs false?
[20:49] <hatch> does undefined signify that it didn't work? I'm thinking no because js fn's return undefined by default
[20:50] <rick_h__> hatch: hmm, true
[20:50] <rick_h__> I guess I like throw then tbh. You asked for something it cannot/will not do
[20:50] <rick_h__> right?
[20:50] <hatch> right, but I don't think YUI throws anywhere
[20:50] <hatch> it just returns some value
[20:50] <hatch> so you don't have to try/catch everywhere 
[20:51] <hatch> I'd prefer throwing also :)
[20:51] <hatch> but doesn't really follow a convention 
[20:51] <rick_h__> meh, it's clear as day, error in the console, I'm +1 on throw if it's for our use anyway
[20:51] <hatch> ok throw it is
[20:51] <rick_h__> and if we want to upstream it I'd suggest we get feedback on upstream
[20:51] <rick_h__>  /on/from
[20:51] <hatch> nah - they will want tests and everything
[20:51] <hatch> too much work to upstream it lol
[20:52]  * rick_h__ leaves for the day before he starts anything :P
[20:52] <hatch> (ok maybe that's just lazy) :P
[20:52] <rick_h__> have a good night all
[20:52] <hatch> hahaha
[20:52] <hatch> cya, enjoy your night
[20:52] <hatch> I'll ask huw about the widget
[20:52] <rick_h__> yea, I'll be online sometime tnoight to bug him on that and his expenses
[20:52] <hatch> oh ok cool
[20:52] <rick_h__> thanks for the help
[21:00] <Makyo> jujugui can I get another quick review on https://github.com/juju/juju-gui/pull/502 ?
[21:01] <hatch> done
[21:01] <hatch> ^ Makyo
[21:04] <Makyo> Thanks hatch 
[21:04] <Makyo> hatch,  do you have Privacy Badger installed?
[21:05] <Makyo> It's blocking some github avatar URLs for me.
[21:22] <bac> Makyo: i use ghostery.  is the badger newer, shinier, better?
[21:24] <hatch> Makyo:  I don't 
[21:26] <hatch> oo boy do I hate errors from within YUI
[21:35] <hatch> wow....ok do not use Object.create(null) if you're going to ever use that object in YUI
[21:35] <hatch> heh
[22:07] <Makyo> jujugui anyone have the latest MV design handy?  I lost my tab :(
[22:08] <hatch> sorry not here - I can't keep all their designs straight lol
[22:11] <Makyo> It's a real problem
[22:11] <Makyo> I'll do a temporary version, then fix it up tomorrow.
[22:42] <hatch> I don't think the setCommitted and setUnCommitted methods are used in the tokens any longer
[22:45] <rick_h__> Makyo: it's in the "Juju Gui" folder I think. THey keep the latest designs in the drive folder
[22:46] <rick_h__> Makyo: https://drive.google.com/drive/u/1/#folders/0Bzj8yHKHrx6pNkVUTkNPd3RWNTQ/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM
[23:03] <hatch> awww yeah got this working
[23:04] <hatch> oh and look at that, just at EOD
[23:07] <huwshimi> Morning
[23:08] <hatch> ohhh look who decided to show up!
[23:08] <hatch> :P morning
[23:08] <huwshimi> :)
[23:10] <huwshimi> hatch: How's the delta stuff coming along?
[23:10] <hatch> good I just finished it - functionally complete anyways
[23:10] <hatch> needs cleanup and tests now
[23:11] <hatch> how we set the committed and uncommitted stuff needs to change into the models....not sure why it's a token level property
[23:11] <huwshimi> Nice!
[23:14] <hatch> yeah but now tokens stay uncommitted for a while while we wait for juju to ack the changeover haha
[23:14] <hatch> so will need another ui state
[23:16] <huwshimi> hatch: I guess that might be helped somewhat if there is a progress bar at the bottom, so you know things are happening
[23:17] <hatch> yeah there are a few different approaches for sure
[23:17] <hatch> I sent off an email to peeps about it
[23:19] <hatch> well I'm stepping away for a bit
[23:19] <hatch> huwshimi:  rick_h__ wanted to talk to you about where you were at with the widget
[23:19] <hatch> just a heads up he'll be popping back in sometime tonight
[23:20] <hatch> bbl
[23:20] <huwshimi> hatch: I'm trying to figure out how to render the dummy element before it gets render for real
[23:21] <hatch> not sure I understand?
[23:21] <hatch> wana have a quick call?
[23:21] <huwshimi> hatch: Well, I have to display a button, that turns into the real menu on hover, so I have to have some dummy elements that exist outside the widget
[23:22] <hatch> that's not what I was suggesting 
[23:22] <hatch> I was suggesting that each token had a ... which was visible when hovered
[23:22] <hatch> when the user clicked the ... it would render the widget for the menu
[23:24] <huwshimi> hatch: I know but rick said to do the init first, so I'm trying to get it to replace the elements rather than appending a new bouding box container
[23:24] <huwshimi> Also, the ... menu is visible before hover
[23:25] <hatch> ohh noo the ... is just a dumb dom element
[23:25] <hatch> you don't need to render the widget
[23:25] <hatch> you can instantiate it without rendering it
[23:26] <hatch> then when someone clicks the .. it renders the widge
[23:26] <hatch> t
[23:26] <huwshimi> I know, but, I have to then get the inited widget to listen for the clikc on the dummy elemnt, but I can't because it creates it's own bounding box
[23:26] <huwshimi> it's ok, I have it under control, it's just a pain :)
[23:27] <huwshimi> Actually, you're correct, the more menu does appear on hover (despite what the mockups show)
[23:27] <hatch> nooooooooo you put a delegate handler on the machine view container which then calls the tokens 'rendermenuwidget' method
[23:27] <hatch> then you only have one event handler for infinite tokens
[23:28] <huwshimi> Ah sure, that's a good idea
[23:28] <hatch> :) 
[23:29] <hatch> ok I'm really leaving for a bit now
[23:29] <hatch> :) be back in like 45mins
[23:30] <huwshimi> bye