[00:54] huwshimi: +1 to wht hatch said. Make the parent token deal with show/hide of the widget [00:55] huwshimi: also heads up, I added a card, there's supposed to be a 'more menu' on each unit on hover as well. [00:55] huwshimi: I'm not sure how that works with this 'hover' thing though. it seems a bit messy [00:55] huwshimi: but the idea is that's how we expose the 'destroy unit' control for each unit in a machine/container. [00:56] rick_h__: OK, np [01:16] huwshimi: also wanted to poke you about expenses [01:16] rick_h__: Oh yes, thanks, I need to do that :) [01:18] :) [01:41] huwshimi: if you'd like I can take a look at what you've got so far [02:40] hatch, rick_h__: So, if the click handler is on the machine view, how do I figure out what object to attach the more menu to? Just do a bunch of dom queries? The parent could be an unplaced unit, a machine token, a container token, a unit on a container token, a column header etc. [02:42] I guess on the dots icon I could attach a data-type="unplaced-unit" data-id='wordpress/0' [02:45] huwshimi: hey sorry I was outside [02:45] yep you're correct [02:45] that information will go along for the ride with the click event so you'll have it all available in the handler [02:46] yuck [02:46] ok :) [02:46] huwshimi: you can also query the parent [02:46] e.currentTarget.ancestor('.token') [02:46] for example [02:46] but the former is much more performant [02:46] because you don't need to do any additional queries [02:46] hatch: That's true, but I'd have to run through a bunch of different DOM queries till it matched the correct type [02:47] the tokens aren't all identical? [02:47] The parent could be an unplaced unit, a machine token, a container token, a unit on a container token, a column header etc [02:47] It's not just tokens ^ [02:47] right, but can't you tell what it is by querying the container of it? They don't all share a common class? [02:48] Why would they? [02:48] in any effect the 'best' is to include the metadata on the element being clicked [02:48] yeah [02:48] it's not yuck, it's really the most performant way of doing it [02:49] at that point you can even instantiate the widget and render it all at once instead of instantiating when we render the machine view [02:49] hatch: Well, it's going to require making sure we copy and paste the correct html all over the place [02:50] (can't even use a partial as we need to set the data attributes) [02:50] partials can have fields [02:50] handlebar properties that is [02:50] Oh [02:51] Like a 'with foo=bar' kind of thing? [02:51] no just like normal handlebars templates [02:52] it would also be super easy to figure out if you forgot to add it to your respective template in the handler ` if (e.currentTarget.getAttribute('data-type') === '') { console.error('yo messed up dude'); } [02:53] huwshimi: http://yuilibrary.com/yui/docs/handlebars/#partials [02:53] hatch: I guess on each view that will contain a more menu we could pass some standard attrs, 'more-menu-id' and 'more-menu-type' or something [02:54] I don't understand [02:55] the ... will be rendered in the token [02:55] the token knows what kind it is [02:55] and what it's id is [02:55] so it can pass that into it's template when it generates the ... [02:55] hatch: Yes, but it's not always a token! [02:56] ok so the only special case is the headers? [02:56] no [02:57] what are the other areas where it needs to be shown that's not a token? [02:58] well, there are three types of token to begin with [02:58] ok that doesn't matter [02:58] each token will know what it is and what it's id is [02:59] I know, but what I'm saying is we need to pass parameters with standard names so the partial can use them [02:59] It's not a problem, it's just something we have to do [02:59] oh right - but that can be within the token though [02:59] nothing special needs to be passed around [02:59] just data it already has [03:00] I didn [03:00] the header menus though could have individual listeners if that makes it easier [03:00] there is only 2(3?) of them [03:00] I'm not talking about passing that around, I'm just saying when we render the html we have to set the params, that's all [03:00] ohh right [03:01] we keep a reference to the token collections in the MV, right? [03:02] yes [03:03] so a trivial lookup once you have all the data [03:03] excellent [03:03] huwshimi: you can setup data on the init [03:05] rick_h__: thought you'd be interested to know I'm looking at typescript for the gui...ooooooo...... :) I ran into some type related issues doing this stuff today, would have been nice if we had them defined [03:06] :) [03:06] want types, do Go :P [03:06] rick_h__: Differently to have them set through data-id data-type? [03:06] rick_h__: haha, go2js :D [03:06] huwshimi: sorry, was thinking that the widget is init from the View and it knows who it is. [03:07] yeah :( [03:07] huwshimi: but sounds like you guys had a long chat about things [03:07] :) [03:08] I'd have each token deal with it's own responsbiilty myself (until we hit a scale issue) [03:08] I still think it should have a single menu which it just renders into the different spots so we only have to instantiate one :) [03:08] though I'm very nervous on all this 'hover' stuff [03:08] hatch: :( [03:08] but I think I'm losing that battle lol [03:08] hatch: but now you've basically got a global [03:08] * hatch hands out flyers [03:09] well in the mv, yes, but there will only ever be a single tooltip window open at once [03:09] hatch: I'm all for trying to cheat performance but I'm +1 on making it work in a clean way first and then optimize [03:09] hatch: yea, but the complexity of it having to know about all 'types' it could be/etc is just so messy to me [03:10] * huwshimi has no idea what to do now :) [03:10] I'm going to talk with Luca about this hover stuff [03:10] I think that's going to be a disaster, click is the way to go [03:10] lol [03:10] huwshimi: do what you were already doing [03:10] just have to figure out something for units [03:11] hatch: Except that you and rick have different opinions :) [03:11] huwshimi: sorry, don't mean to complicate this for you. [03:11] I had already stepped down on my idea in favour of meeting in the middle on having 1M click event handlers [03:11] heh, when we have the 1M machines/units we'll have other issues :P [03:12] lol [03:12] seriously though, we know how we'd optimize this stuff. It moves the same code up the stack one layer from token, to column, to MV itself. [03:12] but each one gives us a trade off of debugging/complexity it seems to me [03:13] huwshimi: each token instantiates its own menu, one click handler for all ...'s, render the menu when the handler says so [03:13] OK, I'm going to abandon this for now and move onto something else [03:13] huwshimi: hatch call? [03:13] huwshimi: sorry, don't get frustrated with it :) [03:13] :) sorry huwshimi it was a discussion, didn't mean to change your mind [03:13] +1 [03:13] you were doing the right way [03:13] rick_h__: It's not a problem, I just don't want to keep re-coding it :) [03:14] this is just hatch and I going back/forth [03:14] huwshimi: understood [03:14] huwshimi: what are you implementing? [03:14] rick_h__: I have not idea any more :) [03:14] huwshimi: I didn't make out the final decision in the back trace [03:14] https://plus.google.com/hangouts/_/gym44xuoo2zqrcqjpb2hdgfmhaa?authuser=1 [03:14] rick_h__: Maybe I should leave it for today and tomorrow you and hatch can make a plan, and then I'll implement that [03:15] joining [03:23] it was so nice and sunny there huwshimi [03:23] haha [03:25] :) [03:26] hatch: This is a webcam of the city: http://www.rosebay.tased.edu.au/webcam/medium.jpg [03:27] hatch: Most of the snow has melted [03:27] huwshimi: you have green grass.....there was no snow [03:27] lol [03:28] hatch: We really only have snow at the top of the mountain [03:28] and wow, maybe I'll move there, I bet the kiteboarding on that lake would be awesome [03:29] lake....ocean whichever :) [03:29] that's actually a river up from the sea :) [03:30] quite the river :) [03:31] hatch: I live about the center of that shot [03:32] You can kind of see my hosue [03:32] better watch out, come winter I may just show up at your house :D [03:32] I'll be on the news "some strange Canadian is going door to door asking for a huwshimi" [03:33] :) [03:33] hatch: It's winter here now, about 12C [03:34] 22 here now, but you can feel winter is coming in the mornings [03:34] the crisp morning air is starting [03:34] pleasant [03:34] yeah it's really nice, it's fly season though [03:34] bleh [03:35] I think I prefer mosquitos [03:35] mosquitoes [03:37] hatch: Are they mexican mosquitoes? [03:37] ours are the size of your spiders.... [03:37] lol [03:37] not sure if that makes them mexican or not :) [04:14] hatch: Every menu has a close-on-click-outside event, should I only attach this when the menu is opened and detached when it is closed? [04:15] huwshimi: yeah that would be best [04:15] ok [04:17] huwshimi: since you're using widgets there is a bindUI method which you can call that you can use to attach your events, then you'll need to create an unBindUI method to do the opposite :) [04:17] it would normally be done on destroy but we aren't destroying them [04:18] yeah [04:56] huwshimi: I'm going to head out now, any q's or anything before I do? [04:59] hatch: All good, Thanks for all your help! [04:59] np, sorry to get you side tracked for a bit there :) [04:59] have a good night [04:59] cya === urulama-_ is now known as urulama [07:57] frankban: morning [07:57] urulama: hi [07:57] urulama: I replied to your last review comment, thanks for the review! [07:59] frankban: the archive size is ok then. and URL.Reference is to be resolved on the API level? [08:00] urulama: we expect the url to be already resolved at the time meta endpoints are invoked [08:00] frankban: thought so, just checking. thanks for the PR. [08:01] urulama: cool, landing it [08:02] frankban: the /meta/bundles-containing is probably similar to this one [08:03] rogpeppe1: morning, sir :) [08:03] urulama: yo! [08:03] urulama: yeah, it has some similarities, and I think it could live in relations.go as well [08:03] rogpeppe1: how was your extended weekend? [08:03] frankban: hiya [08:03] urulama: very fine, thank you [08:03] morning rogpeppe1 [08:04] frankban: exactly, i think it could go there as well [08:04] urulama: cool [08:04] urulama: i'm in Whitby and there's a folk festival going on... [08:04] rogpeppe1: uuuuu, sounds nice! doing any performaces? [08:05] urulama: not really, a bit of playing for some sword dancers with one spot at the late night extra on friday night, but not too much [08:06] rogpeppe1: i would love to get a picture of that, if possible :) i'll tell my boy, he'll love it (huge Zelda game fan and fan of swords) [08:06] urulama: they're kinda strange swords [08:07] urulama: they've got a handle at each end [08:07] * urulama automatically associates UK with knights (of the round table) :) [08:08] urulama: this kind of thing: https://www.youtube.com/watch?v=3WJKiMe-Czk [08:12] rogpeppe1: wow, so many hands! [08:12] urulama: it works well in small spaces - perfect for english pubs [08:14] urulama, frankban: i'm updating the charm API document to cover PUT to the bulk request endpoints [08:15] rogpeppe1: this one? PUT meta/$endpoint[$otherflags] [08:15] urulama: yup [08:16] urulama: and the $id/any endpoint too [08:18] rogpeppe1: if we update meta enpoint, the revision should bump up automatically, right? [08:18] urulama: my current thought is that is does not [08:18] urulama: i think the revision should pertain to the archive, not the metadata [08:19] rogpeppe1: but with changing the meta, one can change the interfaces that are required and exposed, which probably is a new version [08:19] rogpeppe1: or config [08:19] urulama: no, a PUT to the metadata cannot change any of the charm or bundle metadata [08:20] urulama: the only thing we're going to allow a PUT to, for the moment, is extra-info [08:20] rogpeppe1: aaaa, ok. then it makes sense [08:20] urulama: if you want to update the charm or bundle metadata, you will need to upload a new archive [08:54] jujugui: i'll be unavailable next hour as we have an induction session [08:54] urulama: ok [09:04] rogpeppe1: for expand-id, I am not sure by reading the spec if we want to return a 404 in the case the given URL cannot be resolved [09:05] frankban: what do you think we should do? [09:06] rogpeppe1: if we want to avoid changing the URL resolving in the router, then we can keep returning a 404. but we must change the second example in the spec [09:06] (wordpress-34) [09:06] * rogpeppe1 looks [09:07] rogpeppe1: if we return a 404, when you provide a fully qualified URL I'd expect that URL to be included in the results [09:07] frankban: interesting question [09:07] frankban: currently, that would work ok [09:08] frankban: as when the URL is fully specified, we don't make a round-trip to check that it's actually there [09:13] rogpeppe1: yeah, so we have an inconsistency. precise/no-such-42 would return a 200-empty-list result, while just "no-such" a 404 not found error [09:15] frankban: i wonder if we should return a 404 for any expand-id request that expands to no ids [09:15] rogpeppe1: one solution could be returning a 404 if the list is empty [09:15] heh [09:40] rogpeppe1: here is the result: https://github.com/juju/charmstore/pull/76 I need to be afk for a while, see you later [09:40] frankban: brilliant, thanks. [09:40] frankban: looking [09:46] rogpeppe1, frankban: wouldn't it make sense for expand-id on a fully qualified charm url to return 200 and the same url? why 404? [09:46] rogpeppe1, frankban: and for any "no-such-charm", either with series or without, would result in 404 [09:47] urulama: what if the id is fully qualified, but there is no charm with that id? [09:48] rogpeppe1: what sense does it make to expand-id on an id that does not exist? [09:49] get non-exitising-name should return 404, get non-exiting-name/expand-id as well [09:49] urulama: we need to define the API's behaviour in that case [09:49] urulama: so expand-id on a fully qualified charm url might return 404 when there are no results, right? [09:50] rogpeppe1: i would say so, because the ID itself in that url is not valid [09:50] urulama: ok. i think that was the plan, so i'm not quite sure what you're suggesting. [09:52] rogpeppe1: just jumping late into the conversation :) (and as i saw returning 200 on precise/no-such-42) [09:52] urulama: that was frankban talking about previous behaviour, i think. [09:54] rogpeppe1: regarding bson.M vs bson.D ... it is always better to use bson.M? [09:55] urulama: I always use bson.D except when I actually need the map-like capabilities of bson.M [09:55] urulama: creating a slice is cheaper than creating a map [09:55] rogpeppe1: ok, tnx, noted ;) [11:27] morning party people [11:28] urulama: rogpeppe1 but with extra-info can we update that sans-upload? [11:28] rick_h__: yes [11:28] urulama: rogpeppe1 we're looking at using that mechanism to update charms with test results, etc [11:28] ok cool [11:29] rick_h__: that's the raison d'etre of extra-info [11:29] oh heh, needed to keep reading the history there you guys cover that :) [11:36] rogpeppe1: should we use bson.D eve in the cases bson.M is more representative of the concept we are expressing? e.g. we need to map keys to values [11:36] rogpeppe1: e.g. bson.M{"baseurl": id} [11:37] frankban: if bson.M is providing some actual program-construction value, then by all means use it. [11:37] frankban: but in general, bson.D is exactly equivalent in representation [11:37] frankban: it represents a mapping of keys to values just like bson.M does [11:38] frankban: but it's a little more efficient, so i prefer to use it, all other things being equal [11:40] rogpeppe1: I read bson.M{"baseurl": id} slightly better than bson.D{{"baseurl", id}}, but perhaps it's just because I am used to express this kind of queries as a key/value, rather thank i[0]/i[1] [11:41] frankban: yeah, bson.M is cognitively closer to what we're trying to represent, but i don't think that means we have to use it. [11:41] rogpeppe1: in this case the query is really easy to read anyway, so I'll just make the change for efficiancy [11:41] frankban: thanks [11:41] efficiency even [11:43] rogpeppe1, frankban: would this apply to the PR75 as well? I guess bson.M and bson.D are properly used there, but maybe take another look [11:44] * rogpeppe1 looks at PR75 [11:45] frankban, urulama: yeah, i'd use bson.D there [11:55] urulama: would you like to take a look at https://github.com/juju/charmstore/pull/76? [11:55] frankban, urulama: in a very quick-and-dirty benchmark, bson.D is about twice as quick as bson.M: http://paste.ubuntu.com/8088225/ [11:56] frankban: i think that you and rogpeppe1 already covered it, so, i think its +1 [11:56] urulama: cool thanks [11:59] rogpeppe1: I'd be interested in the meaning of "twice as quick" in the context of a full request/db query/response [11:59] frankban: sure, it's probably lost in the noiser [12:00] frankban: but it's nice to be efficient when there's no cost in doing so [12:00] s/noiser/noise/ [12:01] rogpeppe1: +1 except in the cases there is some other cost, like readability. but perhaps it's just me, perhaps I am just not used to things like "}}}}," ;-) [12:02] frankban: :-) [12:02] frankban: i don't think it's too bad. [12:03] frankban: can't you tell at a glance that's 5, no I mean 4 closing braces? :P [12:04] heh [12:04] frankban: if you get some downtime, think you can help jrwren_ out and peek at his merge proposals on quickstart this week? [12:05] frankban: help clear out the slack stuff pending and might be good to see if it can land and make sure we get a final quickstart release for the cycle in the near future. [12:07] * urulama needs to grab some food [12:07] * rick_h__ sends some leftovers to urulama [12:07] rick_h__: I remember I reviewed all those slack cards [12:08] frankban: oh did you? awesome, I'll maybe bug jrwren_ about them then. [12:11] rick_h__: :D :D [12:11] rick_h__: I did it before London. I did not receive other emails re those branches [12:11] frankban: ok, I was just looking at the board and figured it might be cool to move those forward. I'll check up on it thanks. [12:12] rick_h__: thank you [12:13] * rogpeppe1 grabs some lunch too [12:37] frankban: did you review them a second time? I've been delaying nagging you about them. I did address all 3. [12:38] but since rick_h__ is nagging for me, I should probably nag. [12:38] err, I mean asking ;] [12:39] jrwren_: I reviewed them once, then did not receive any signal they are ready for re-review. If they are ready, I'll take another look at them asap [12:39] frankban: Yes, please do. [12:39] jrwren_: ok [12:57] oh luca, o'buddy o'pal [13:00] rick_h__: heya :) [13:01] luca: got time for a quick chat? [13:01] rick_h__: in a meeting for the next 2 hours [13:01] I want to get your brain on it asap :) [13:01] luca: ok, if you get free ping me otherwise we can chat tomorrow [13:02] rick_h__: will do [13:02] ty much [13:58] rick_h__: i see a bunch of cards in tracking for GUI, but they seem to be defects in our code (e.g we're not tracking another project) what's up with those? [13:58] rick_h__: got a question for you when you have a moment. [13:59] jcsackett: I pulled them aside as I think they were worked on but not verified yet [14:00] jcsackett: working on the board, will update htem [14:00] kadams54: otp, will ping when off [14:05] rick_h__: so i can tell you the one for "dispatched urls" had some investigation done, but we concluded it's blocked until we release MV 1.0, so we're rid of the ghost inspector. happy to chat with you about details if you want. [14:06] jcsackett: ok cool, will move it back into the on deck [14:06] jcsackett: can you update the bug with any notes to help getting it started and the MV 1.0 reasons/etc? [14:06] kadams54: free, what's up? [14:09] rick_h__: sure. [14:18] rick_h__, bac: I'd like your opinion on https://code.launchpad.net/~evarlast/juju-quickstart/which-juju/+merge/227238 . Do you have a minute to take a look? thanks [14:19] frankban: looking [14:20] frankban: oh hmm, interesting. *thinking* [14:22] frankban: jrwren_ so the issue is sudo $JUJU, so I'd just stop that. Don't allow it. It's an older scenario and we can say the feature isn't backwards compatible. [14:22] frankban: I completely missed that first comment. [14:22] frankban: jrwren_ so if a user has $JUJU set and we need to 'sudo $JUJU' we output a warning and don't use it [14:22] frankban: jrwren_ bac thoughts? [14:25] rick_h__: sounds reasonable, given we have a use case for this feature. use a compiled version of juju? I am still worried about point 2) in my comments [14:26] frankban: yea, I think with the call for testing and such we'll have to get past #2. For CI for instance, we'd easily use $JUJU=xxxx to test against upcoming Juju versions [14:26] frankban: I'd not shout the feature from the hill tops, but I think it makes sense to support it [14:26] I want the sudo feature for myself :) [14:27] rick_h__, jrwren_, coll then +1 [14:27] I'd rather doc it with a giant warning or something. [14:27] jrwren_: what for? We don't need sudo in modern lxc, this will be released in utopic quickstart, not any earlier versions [14:27] rick_h__: quickstart local? [14:28] rick_h__: err, just bootstrap local. [14:28] jrwren_: yea, isn't the sudo requirement for local bootstrap gone? [14:28] well, at least quickstart doing it [14:28] juju deals with sudo now, we don't have to [14:28] rick_h__: oh, but I see. yes, that is the difference. [14:29] in that case I agree with all the concerns and I should update the PR. [14:29] jrwren_: ok, let me know if I'm off in my thinking. [14:30] jrwren_: frankban ok, so we're +1 on ignore $JUJU on any sudo call paths, respecting it otherwise, and making sure we hide it from non-test users ) [14:30] :) [14:30] rick_h__: No, I think the two points in frankban's initial comment are still important and shall be addressed. [14:31] rick_h__: s/No/Yes/ :) [14:31] rick_h__, jrwren_: added a new comment summarizing this chat [14:31] ty frankban [14:31] thanks for the updates jrwren_, sorry for the complication. [14:31] and thanks for the good call/catch on sudo frankban! [14:36] I just used local yesterday and needed to enter my pw [14:36] on 1.20.1 [14:37] hatch: right. juju invoked sudo on your behalf. you didn't have to invoke juju with sudo, did you? [14:38] jrwren_: no, but I did have to type my pw [14:38] so it still rquired sudo [14:47] hatch: yes, but it's not quickstart's issue so it's not an attack vector [14:47] every time i see "attack vector" I think of a top down airplane game [14:47] pew pew [14:47] pew! [14:48] :-) [14:49] jrwren_: https://code.launchpad.net/~evarlast/juju-quickstart/support-lxc-clone/+merge/227250 done [14:49] frankban: thanks! [14:49] jujugui call in 10, please update kanban [14:57] rick_h__: I’m free for a call [14:57] luca: standup time [14:58] luca: can ping afterwards [14:58] rick_h__: ok [14:58] jujugui call time in 2 [14:59] Makyo: kadams54 frankban ^ [14:59] antdillon: ^ [14:59] joining [15:13] doh! [15:13] come on chrome, go go go [15:15] geeze, what's a guy have to do to run a meeting around here? [15:15] rick_h__: the FX are great :) [15:49] man, I wish I had a recording of how I sounded :P [15:52] My inlaws had a problem with their landline phone awhile back. It would make them sound like a chipmunk, but only the person on the other end could hear it. It was also sporadic, so one minute you'd be having a normal conversation, the next, Alvin and the chipmunks. [15:52] It was awesome. [15:52] hah [15:55] so, if we have a machine with the only uncommitted unit of an uncommitted service, and we delete that machine, should we just reset the unit as an unplaced unit, or should we clear the service? [15:56] jcsackett: I'd reset it as an unplaced unit [15:56] and then they can remove it from there if they like [15:56] rick_h__: ok, that was the way i was headed. [16:09] jrwren_: reviewed the third branch, it looks good with minor changes, thank you [16:11] luca: hey the svg rendering bug you reported - was the image you had stitched together? The only way I can reproduce it is if one icon straddles the bottom of the browser so that only part of it is rendered [16:12] so I can't get two icons to not render properly [16:13] hatch: I didn’t stitch them together, that just how they appear in the listing [16:13] hatch: I’ll send you another pic of the same bug [16:14] hatch: check you email [16:15] thx [16:15] hatch: sent another too [16:15] woah I haven't seen that one [16:15] hatch: it might show it a little better [16:15] hatch: yeah, it all happened at the same time [16:15] hatch: it started during the London sprint [16:15] *sigh* I've been researching chrome svg rendering bugs but I can't reproduce anything like this using any svg's that aren't ours [16:15] frankban: thanks again. [16:16] but they also don't happen in any other browser.... [16:16] hatch: It seemed to happen when my browser updated [16:16] hatch: and it can be consistently reproduced on other peoples browsers in the web team [16:18] luca: yeah it's definitely a chrome bug, but nothing that matches this has been filed (and not subsequently fixed) and any other svg's but our icons don't exhibit the same problem [16:19] hatch: ok [16:19] hatch: so we can’t fix it? [16:19] luca it also seems to only happen with certain icons [16:19] the wordpress icon for example is really bad, but the icon for ubuntu-repository-cache doesn't appear to exhibit the issue [16:19] hatch: yeah, I couldn’t work out why it would effect some and not others [16:20] I'll put my notes in the bug and we can revisit, I'm guessing there is something wrong with how some of the svg's are created [16:20] and with how chrome's new rendering works [16:20] hatch: the MySQL icon on the service block doesn’t respond the zoom, thats why it looks wrong [16:21] hatch: sent you another img [16:22] odd I can't reproduce that one [16:22] luca can you add these images to the bug? [16:23] sure [16:23] thanks, it's very odd, even in osx with the same version of chrome i can't reproduce what you see [16:24] I wonder if you have some extension which may be making it worse heh [16:48] oops, I ate too many nibs [16:49] hatch: I get it based on zoom levels sometimes. [16:49] hatch: it's not an extension, it seems something in chrome/svg resizing or something [16:50] rick_h__: right, I just can't reproduce the same issues so was just trying to find some reasoning behind that [16:50] you'd think identical os's and browser versions would do the same thing haha [16:50] hatch: heh [16:50] I get it on linux in the dev edition [16:50] Chrome in Ubuntu is such a mess [16:50] :) [16:50] when I drag a window it goes transparent [17:00] jujugui: have a nice evening [17:00] cya urulama [17:00] u 2 [17:00] and you [17:02] * rogpeppe1 is done for the day too. [17:02] g'night all [18:13]