#instantbird log on 12 12 2012

All times are UTC.

00:06:46 --> rosonline has joined #instantbird
00:14:46 <rosonline> Hello! My facebook friend is trying to call me and this text appears:
00:14:54 <rosonline> START_SESSION0ce7c47c-6d21-40f9-b479-bddb02765b62falsefalsefb:ac50cbctmsu1u4axteeruhazwcs5e_barj0we2hmlic5qmvruxeeisc70zn9umyxfdofb:ac7q9mtbktbvzmru07wah-rf3axdyunsdkxu_am74pav5e6ryup92wqrfi9buhzhk24
00:15:10 <rosonline> and
00:15:11 <rosonline> CANCELLED_CALL0ce7c47c-6d21-40f9-b479-bddb02765b62
00:15:35 <clokep> rosonline: Are you on a nightly?
00:15:41 <rosonline> No
00:15:45 <clokep> Ah, OK.
00:15:48 <rosonline> Instantbird 1.3
00:16:05 <clokep> Well we don't currently support video calling, but it could be interesting to see the debug output. ;) I think flo has looked at this a bit though.
00:17:09 <rosonline> Maybe We can warn the user that Instantbird doesn't suport video (like as string)
00:23:59 <rosonline> Should bug I this fact?
00:24:15 <clokep> Sure, file a bug.
00:24:24 <EionRobb> wow, interesting
00:24:49 <clokep> EionRobb: Careful, I'll kick you.
00:25:02 <clokep> rosonline: If you want to get a debug log and attach that, it might be helpful (scrubbed of personal information).
00:25:09 <EionRobb> no, the interesting bit is the string that comes through from facebook
00:25:15 <clokep> Ah.
00:25:18 <EionRobb> its got the two skype ids in there
00:25:29 <EionRobb> fb:ac50cbctmsu1u4axteeruhazwcs5e_barj0we2hmlic5qmvruxeeisc70zn9umyxfdo and fb:ac7q9mtbktbvzmru07wah-rf3axdyunsdkxu_am74pav5e6ryup92wqrfi9buhzhk24
00:25:34 <clokep> base 64 encoded?
00:25:39 <-- rosonline has quit (Ping timeout)
00:25:47 <EionRobb> randomly generated, from what I've seen
00:26:04 <clokep> Interesting, so what protocol is it underneath? Is it Skype or is it XMPP's libjingle garbage.
00:26:13 <EionRobb> I've tried using the regular skype client to do the calls but the other end never answers
00:26:16 <EionRobb> its skype
00:26:28 <clokep> Weird.
00:26:55 <EionRobb> maybe the session id is important... kinda looks like a skype public chat guid
00:27:41 <EionRobb> need to fire up the latest skype client, linked to the fb account, and see what it does for the calls
00:27:47 <clokep> Hmm....interesting.
00:27:53 <clokep> And confusing. ;)
00:28:35 <EionRobb> nah ;)
00:30:11 <clokep> It almost sounds like they want to make it difficult!
00:31:04 <EionRobb> ;)
00:40:49 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232])
00:43:16 --> rosonline has joined #instantbird
00:50:37 <-- meh has quit (Quit: The point is: don't lose your dinosaur.)
00:54:59 <-- rosonline has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com)
01:21:08 <-- Optimizer has quit (Ping timeout)
01:24:41 --> Optimizer has joined #instantbird
01:26:09 <-- myk has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
01:40:45 <-- Gizmokid2005 has quit (Ping timeout)
01:45:11 --> Gizmokid2005 has joined #instantbird
01:47:43 <-- Mook_as has quit (Quit: Mook_as)
01:58:31 --> jb has joined #instantbird
02:22:18 <-- Optimizer has quit (Ping timeout)
02:24:07 --> Optimizer has joined #instantbird
02:28:40 <clokep> from devel@pidgin: http://pastebin.instantbird.com/112521
02:29:06 <clokep> Also, my Moz17 build is hitting an assertion. :(
02:32:35 <clokep> Hm....but only when in libpurple, if I open just JS accounts I just get lots of exceptions...
02:43:38 <-- Optimizer has quit (Ping timeout)
02:44:05 --> mconley has joined #instantbird
02:46:38 <-- clokep has quit (Connection reset by peer)
02:47:02 --> Optimizer has joined #instantbird
02:47:27 --> clokep has joined #instantbird
02:47:27 * ChanServ sets mode +o clokep 
02:48:01 <-- clokep has quit (Connection reset by peer)
02:49:03 --> clokep has joined #instantbird
02:49:03 * ChanServ sets mode +o clokep 
02:50:57 <-- Optimizer has quit (Ping timeout)
02:54:23 <-- jb has quit (Ping timeout)
03:00:17 <EionRobb> that eionrobb chap sounds like he knows what he's talking about
03:00:23 <EionRobb> I'd trust him
03:01:27 --> DGMurdockIII has joined #instantbird
03:04:38 <clokep> I didn't really want to call you out on it EionRobb, but yeah. :P
03:04:47 <clokep> Feel free to ping me though if people ask about Instantbird or Thunderbird.
03:08:21 --> Mook has joined #instantbird
03:09:40 <EionRobb> my answer was the same as yours without being all technical about it :)
03:10:26 <-- SM0TVI has quit (Connection reset by peer)
03:10:42 <EionRobb> probably doesn't help that I got confused between Thunderbird and Instantbird :P
03:11:11 <EionRobb> but they wouldn't see MSN/OSCAR etc if they didn't have the libpurple extension installed in Thunderbird
03:12:19 <clokep> Yup!
03:21:31 --> SM0TVI has joined #instantbird
03:27:10 <-- dew has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com)
03:29:06 --> Optimizer has joined #instantbird
03:30:39 <clokep> For anyone interested, I put in a Whitelist request with Symantec.
03:30:52 <clokep> I'm not going to forward it to team@ though since it has my phone number in it. ;)
03:32:52 <SM0TVI> clokep: Wat? IB got classified as malware?
03:33:39 <clokep> SM0TVI: There were a few reports of it for the 1.3 release, (the reports were "unknown software" not that it was thought to be malware).
03:33:46 <clokep> We reported it as a false positive and it was taken care of within days.
03:33:58 <SM0TVI> Ah.
03:34:05 <clokep> Whitelisting would be preemptive action to not have that happen again. :)
03:34:41 <SM0TVI> It sometimes happens that you get a false positive during scans (as in a hash collision).
03:35:55 <instant-buildbot> build #709 of linux-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/709
03:37:07 <clokep> Yeah I don't care much about the reasons...mostly about not having our users have issues. :)
03:37:50 <SM0TVI> clokep: It's a rarity tho - I've only encountered it myself like once in 6 years.
03:38:14 <clokep> Right.
03:40:08 <-- Optimizer has quit (Ping timeout)
03:42:49 <-- Kaishi has quit (Quit: Kaishi)
03:43:31 --> Optimizer has joined #instantbird
03:53:52 --> dew has joined #instantbird
03:56:34 <-- Optimizer has quit (Ping timeout)
04:00:10 --> Optimizer has joined #instantbird
04:08:00 <-- mconley has quit (Input/output error)
04:13:36 <instant-buildbot> build #711 of macosx-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/711
04:42:30 <-- skeledrew has quit (Ping timeout)
04:45:24 --> skeledrew has joined #instantbird
04:45:29 <-- EionRobb has quit (Quit: Leaving.)
05:04:57 <-- clokep has quit (Connection reset by peer)
05:15:44 <instant-buildbot> build #801 of win32-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/801
05:33:26 --> jb has joined #instantbird
05:49:46 --> FireFly_TB has joined #instantbird
05:58:46 <-- FireFly_TB has quit (Ping timeout)
06:04:39 <-- jb has quit (Ping timeout)
07:16:19 <-- Mook has quit (Quit: Mook)
07:18:03 <instantbot> florian@instantbird.org denied review for attachment 2163 on bug 1846.
07:18:05 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1846 min, --, 1.4, aleth, RESO FIXED, Changing the status to available while an IRC account is in the disconnecting state doesn't reconnec
07:52:39 --> Even has joined #instantbird
07:52:39 * ChanServ sets mode +o Even 
08:21:29 <-- Optimizer has quit (Ping timeout)
08:25:02 --> Optimizer has joined #instantbird
08:35:05 --> scribbly has joined #instantbird
08:36:56 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232])
08:42:35 <scribbly> Hey all: I was thinking of trying InstantBird... but the roadmap finishes at version 1.3 -- how can that be??
08:57:32 --> gerard-majax_ has joined #instantbird
09:05:26 --> Even1 has joined #instantbird
09:10:15 <scribbly> I was wondering why the roadmap didn't extend beyond the current version?
09:39:04 --> Mic has joined #instantbird
09:39:05 * ChanServ sets mode +h Mic 
09:39:28 <Mic> Hi scribbly
09:39:41 <scribbly> Hey!
09:39:55 <Mic> That just means that no one has updated the roadmap in a while.
09:39:56 <scribbly> Was starting to think no one was in :)
09:40:57 <Mic> We're using other tools like etherpads to brainstorm what we'd like to have in the next version ..
09:42:35 <Mic> And it shouldn't keep you from trying Instantbird ;)
09:46:26 <Mic> Is there anything else I can help you with, scribbly?
09:46:51 <scribbly> Was wondering about the road map
09:47:01 <scribbly> it ends with the current release?
09:49:23 <Mic> clokep, flo, flo-retina: do we have an etherpad with plans for 1.4? I don't remember and I can't find one in my browser history either.
09:52:10 --> jb has joined #instantbird
09:52:51 <Mic> One thing I'd like to do for 1.4 is finally including context messages retrieved from the log files when opening a conversation.
09:53:51 <Mic> One of us is working on including SIPE (MS Office Communicator) as new protocol, so there are lots of things going on.
09:54:25 <Mic> It's just that nobody has written a roadmap entry yet.
10:17:57 --> flo-retina has joined #instantbird
10:17:57 * ChanServ sets mode +qo flo-retina flo-retina 
10:18:24 <flo-retina> still no mac nightly update :(
10:18:32 <flo-retina> I'll really have to look at that update server :(
10:23:10 --> rosonline has joined #instantbird
10:44:36 <-- Optimizer has quit (Ping timeout)
10:48:23 --> Optimizer has joined #instantbird
10:49:18 <-- jb has quit (Ping timeout)
11:04:03 --> clokep has joined #instantbird
11:04:03 * ChanServ sets mode +o clokep 
11:04:46 <-- Optimizer has quit (Ping timeout)
11:16:01 <-- scribbly has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
11:22:01 <clokep> Mic: No, we don't have a 1.4 etherpda.
11:22:14 * clokep doesn't find making roadmaps interesting. ;)
11:22:46 <flo-retina> clokep: it's only interesting in that it lets us know what others are thinking of doing
11:23:27 <clokep> flo-retina: Of course, that's what I included the /making/ :-D
11:24:32 --> qlum has joined #instantbird
11:26:48 <clokep> If we want to make a 1.4 etherpad (or expand the roadmap), we could.
11:26:55 <clokep> When are w ethinking of releasing 1.4 anyway?
11:27:11 <flo-retina> 3 months from 1.3?
11:27:14 <flo-retina> when was 1.3? :-D
11:29:32 --> Kaishi has joined #instantbird
11:30:00 <clokep> November 15th.
11:30:04 <Mic> That would make it 16th of Feb.
11:31:04 <Mic> 15th then..
11:31:25 <clokep> We would clamp it to a good day during the week around there anyway, so the exact day doesn't matter. :)
11:31:50 <flo-retina> does that look possible?
11:32:02 <flo-retina> will there be anything interesting to release by then?
11:32:26 <-- mpmc has quit (Connection reset by peer)
11:32:43 <clokep> I don't think so. :-/
11:32:44 * Mic thought that didn't matter anymore in the age of rapid releases? scnr;)
11:33:09 * flo-retina isn't even sure of what happened since 1.3, except debug logging (that still need a lot of polishing...) and dropping PPC (what a 'feature'!)
11:33:15 <clokep> Any one have any ideas of how to even debug this: http://pastebin.instantbird.com/112700 ?
11:33:25 <clokep> flo-retina: And fixing connecting to znc.
11:33:41 <flo-retina> clokep: people connecting to znc can use nightlies, or are already lost
11:34:07 <clokep> You asked what new features there were, I'm just telling you.
11:34:23 <flo-retina> clokep: maybe add some dumps around http://lxr.instantbird.org/instantbird/source/chat/modules/imXPCOMUtils.jsm#48 ?
11:35:04 <clokep> Bah, caller is a variable name. :( I thought that was a generic error message.
11:35:47 <clokep> Good call.
11:37:11 <flo-retina> clokep: is that on moz17?
11:37:19 <clokep> flo-retina: Yes.
11:37:41 <Mic> I'd really like to fix bug 958, 1511. Bug 1728 would be cool but I've no idea how I could deal with the unicode things that Twitter does :S
11:37:45 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=958 enh, --, ---, benediktp, ASSI, Show last messages (history) in new chat windows
11:37:46 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1728 enh, --, ---, benediktp, NEW, Show mentions of tracked keywords in own conversations
11:37:47 <flo-retina> clokep: it's possible we just need to revert http://hg.instantbird.org/instantbird/rev/a9346a5e39a7
11:37:55 <flo-retina> clokep: we never understood why we needed that anyway
11:38:43 --> clokep_js has joined #instantbird
11:38:49 <clokep_js> flo-retina: Well that seemed to work...
11:39:18 <flo-retina> maybe it was just a temporary gecko 16 quirk...
11:39:51 * clokep_js goes to try a libpurple account.
11:39:55 <-- clokep_js has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
11:40:14 <clokep> Hmm...libpurple ones I still get a dereferencing a null ptr error.
11:41:06 * clokep doesnt' have time to debug that right now.
11:45:55 --> aleth has joined #instantbird
11:45:55 * ChanServ sets mode +h aleth 
11:51:17 <-- Mic has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
11:58:33 <-- clokep has quit (Connection reset by peer)
12:30:35 --> Even2 has joined #instantbird
12:30:59 <-- Even2 has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
12:31:06 --> Even2 has joined #instantbird
12:31:56 <-- rosonline has quit (Client exited)
12:46:54 --> mpmc has joined #instantbird
12:47:54 <-- flo-retina has quit (Ping timeout)
12:47:57 --> flo-retina has joined #instantbird
12:47:57 * ChanServ sets mode +qo flo-retina flo-retina 
12:53:43 <aleth> flo-retina: Do you remember why it's this.prplAccount.connectionErrorReason rather than this.connectionErrorReason here http://lxr.instantbird.org/instantbird/source/chat/components/src/imAccounts.js#243 ? (It's what I followed.)
12:54:43 --> clokep_work has joined #instantbird
12:54:43 * ChanServ sets mode +o clokep_work 
12:57:26 --> meh has joined #instantbird
12:57:38 <aleth> Btw I'd say SIPE on its own is a good enough "visible feature" to justify 1.4
13:00:42 <flo-retina> aleth: possibly a small optimization
13:01:00 <flo-retina> it's possible that code in the patch was fine, I would need to look again
13:01:47 <aleth> flo-retina: I just wasn't sure about what the getter was differentiating for. You may well be right
13:02:10 <aleth> Btw what looks like a null check was actually there to test for undefined.
13:02:45 <aleth> Since we had the same (but less noticeable there) bug in the status observer, as it turns out.
13:04:25 <flo-retina> aleth: it can't be undefined, there's a -1 (NO_ERROR) value in the prototype, isn't there?
13:05:31 <flo-retina> or if you care about the case of missing protocol plugins, you want to do this. instead of this.prplAccount.
13:06:42 <aleth> aha! You're right. I misunderstood what you meant when you said it was deleted on reconnection.
13:11:02 <aleth> So I guess I have to figure out why we're not using the getter (which seems better) throughout the observer.
13:12:12 --> mikk_s has joined #instantbird
13:12:29 <flo-retina> I think it's just a small optimization: if we received notifications from the prpl, we know the prpl exists, and the account isn't in a state (like missing password) that prevents attempting to connect it
13:12:46 <-- mikk_s has left #instantbird ()
13:13:36 <aleth> That makes sense...
13:14:03 <aleth> This code always worries me because it's so easy to overlook something ;)
13:14:19 <flo-retina> it really wants unit tests :(
13:15:36 <aleth> Not easy... you'd have to fake all sorts of connection errors and timings... :-/
13:16:17 <flo-retina> would be worth starting by testing the easy things, and complicating things later ;)
13:16:34 <aleth> sure
13:16:54 <flo-retina> reconnect timers really want some unit test
13:17:01 <flo-retina> we would just need a fake prpl for that I guess
13:17:06 <aleth> yes :(
13:17:20 <flo-retina> it's not difficult to make one ;)
13:17:38 <flo-retina> I think I almost made one for a Tb test
13:17:42 <flo-retina> and I never finished that test :(
13:17:53 <aleth> We have had that bug in the status observer for a while and never noticed, because we tend to run nightlies where accounts are properly configured...
13:18:24 <flo-retina> that bug, you mean the broken reconnect timers?
13:19:09 <aleth> Yes (though those weren't broken before the last patch, the same bug manifested differently)
13:19:16 <flo-retina> I wonder if it could explain the Instantbird nightly that sucked 2GB of ram on my other macbook (when I found it, it was using 2+GB of RAM, and the accounts were all disconnected because the SSH tunnel they use was broken)
13:20:02 <aleth> I don't know - it would only arise if you changed your status from offline.
13:20:16 <flo-retina> no, it doesn't require a status change
13:20:43 <flo-retina> (and that " only arise if you changed your status from offline" part of your comment confused me)
13:21:06 <flo-retina> the bug is that instead of creating a reconnect timer, we reconnect immediately if after an account has finished disconnecting the status is online
13:21:58 <aleth> Yes, that's the bug we introduced with the recent patch
13:22:30 <aleth> But there was already an issue in the status observer: an account which had failed to connect properly would be reconnected immediately when changing one's status, because the same check was missing there.
13:23:20 <aleth> You wouldn't notice that usually because the attempt would fail and it would end there, it wouldn't go into a loop like with the recent bug.
13:24:45 <flo-retina> oh ok
13:24:58 <flo-retina> I'm pretty sure I noticed that once
13:25:13 <aleth> That's why we made the error in the last patch, the code we copied already had that problem in it.
13:30:21 <-- flo-retina has quit (Input/output error)
13:30:22 --> flo-retina has joined #instantbird
13:30:23 * ChanServ sets mode +qo flo-retina flo-retina 
13:31:44 * flo-retina would like to know why he got disconnected
13:32:38 <flo-retina> the 50 items of the debug log are definitely not enough :(
13:34:31 <clokep_work> I agree. :-D
13:35:26 <flo-retina> I think I want the 50 last items of the last few connection attempts that didn't finish cleanly
13:36:36 <flo-retina> this way, if you come back after a few hours and notice in the account manager that your IRC account has been "online for 30 minutes" whereas all other accounts have been connected for 12 hours, you can still look at what happened
13:39:41 <-- qlum has quit (Ping timeout)
13:40:19 <-- Kaishi has quit (Quit: Kaishi)
13:42:22 <clokep_work> Yeah, more messages could be good.
13:42:35 <clokep_work> My guess is the connection dropped for some reason...
13:42:42 <clokep_work> I think I have a patch up for review about that?
13:43:01 --> qlum has joined #instantbird
13:43:04 <aleth> We could simply add the pref and increase the default to 500 or so
13:43:29 <clokep_work> aleth: Where's the patch? ;)
13:43:52 <clokep_work> (But yeah, I agree that we should at least add the pref. :))
13:44:48 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2158 on bug 1850.
13:44:50 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1850 tri, --, ---, nobody, ASSI, Fix indentation of conversation.xml
13:47:09 * clokep_work wonders if aleth would want to review bug 1812.
13:47:12 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1812 nor, --, ---, clokep, ASSI, IRC accounts should timeout when the connection to the server has stalled
13:48:50 --> mikk_s1 has joined #instantbird
13:49:26 <-- mikk_s1 has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com)
13:49:43 <flo-retina> clokep_work: I was disconnected with I/O error in instantbot's log, so I suspect it could be something we failed to parse, or some misformatted message we sent.
13:50:33 <flo-retina> clokep_work: but the connection just being flaky is still a possibility (especially as my freenode account got disconnected approximately at the same time. (gtalk account not disconnected though...)
13:51:36 <clokep_work> I'd guess a misformatted message, I don't see how failing to parse something could cause that.
13:51:55 <flo-retina> clokep_work: that patch (bug 1812) has been waiting because it feels r- even though I can't spot anything wrong in it when looking only quickly :(.
13:51:58 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1812 nor, --, ---, clokep, ASSI, IRC accounts should timeout when the connection to the server has stalled
13:52:12 <flo-retina> clokep_work: well, failing to parse, causing us to mis-reply ;)
13:52:20 <aleth> clokep_work: I don't think so, the changes don't look very IRC specific
13:53:49 --> look has joined #instantbird
13:54:30 <clokep_work> aleth: That doesn't mean I wouldn't appreciate another set of eyes on it. :)
13:55:39 <flo-retina> sure, an additional review wouldn't hurt :)
13:57:07 <aleth> Without looking too carefully - wouldn't you also need to make some changes to twitter.js?
13:58:05 <clokep_work> twitter.js doesn't use socket.jsm.
13:58:23 <aleth> OK :)
14:00:02 <clokep_work> it uses http.jsm or whatever it is called. ;)
14:00:06 * clokep_work suspects oscar will use both. :(
14:03:25 <flo-retina> I guess I'm just not fully convinced that this is something we really need at the socket.jsm level, rather than at the prpl level
14:03:46 * clokep_work was attempting to share code.
14:04:14 <flo-retina> yeah, it does reduce code duplication a bit, but at the cost of making a kinda generic API much less generic
14:04:52 <clokep_work> I don't really see how it is "much less generic". I see it as adding optional functionality.
14:05:28 <flo-retina> maybe my comment is just that we need much better documentation in socket.jsm about how that code is supposed to be used
14:05:29 --> jb has joined #instantbird
14:06:12 <clokep_work> That...I definitely agree with.
14:06:19 <clokep_work> Writing documentation isn't fun. :(
14:06:28 <clokep_work> socket.jsm is fairly generic though, it doesn't assume it is in an account or anything.
14:06:43 <flo-retina> right
14:06:50 <flo-retina> (some accounts could need more than one socket anyway)
14:06:56 <clokep_work> Yup.
14:08:50 <clokep_work> I just see sending a keep alive as something that wouldn't be uncommon when using a socket.
14:13:32 <flo-retina> but the 'API' says "ping" ;)
14:15:29 <clokep_work> If that's your only issue we can rename it keepalive.
14:15:47 <flo-retina> no, r= "needs documentation" ;)
14:16:47 <flo-retina> s/=/-/
14:17:32 <clokep_work> Then r- it and I'll add documentation.
14:17:42 <clokep_work> That's a perfectly reasonable review comment.
14:17:48 <clokep_work> I can also change it to say keepAlive while doing that. ;)
14:18:03 <flo-retina> the documentation can say that
14:18:23 <flo-retina> and maybe "ping" is the right word for a keep alive packet that expects a reply
14:25:44 * clokep_work doesn't understand why people hate putting spaces around operators.
14:39:51 <flo-retina> clokep_work: it's more typing! and the space bar is so small that it's hard to reach on most keyboards ;)
14:40:26 * clokep_work is looking at a 278 character line with no spaces on it.
14:40:39 <aleth> Well, there's your answer :D
14:40:45 <flo-retina> ah, that's to fit the 280 characters limit then! :)
14:41:00 <aleth> exactly :)
14:41:20 <clokep_work> It doesn't fit across my two 23" monitors...
14:41:37 <aleth> Clearly you need a third.
14:41:41 <clokep_work> (Well that's a lie, it does...but it's like 1.75 monitors...)
14:42:07 <clokep_work> Bah you have no idea how hard it was to get a second...
14:42:13 <flo-retina> so you need to add spaces around all operators to have a solid reason to request a third monitor then!
14:42:29 <flo-retina> or where the spaces removed on purpose, so that you don't request that third monitor? :)
14:42:47 <flo-retina> *were
14:43:01 <clokep_work> I'll just put in line breaks...
14:43:34 <aleth> That'll take up vertical space though ;)
14:45:57 --> mconley has joined #instantbird
14:48:50 <-- look has left #instantbird ()
15:03:15 <clokep_work> I could turn a monitor vertically then. ;)
15:49:54 <instantbot> clokep@gmail.com denied review for attachment 2114 on bug 1812.
15:49:56 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1812 nor, --, ---, clokep, ASSI, IRC accounts should timeout when the connection to the server has stalled
15:50:14 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2164 on bug 1143.
15:50:16 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1143 nor, --, ---, aleth, ASSI, Collapsed participant list sometimes loses listitems
15:55:44 <clokep_work> "which are to be fixed in XBL2" haha.
15:57:14 <aleth> yeah, those are not new bugs... ;)
15:58:00 * clokep_work highly doubts xbl2 will ever happen.
16:00:19 <aleth> It's less likely than that they'll ditch XUL/XBL at some point ;)
16:00:22 <aleth> I guess these are XBL edge cases that are not serious enough and/or too expensive to fix.
16:01:36 <aleth> They are not really listbox bugs, but bugs in how/when elements get bound.
16:16:39 <-- jb has quit (Ping timeout)
16:17:57 <-- gerard-majax_ has quit (Ping timeout)
16:59:33 <flo-retina> aleth: isn't your patch causing the XBL bindings of every listitem to be deleted and recreated?
17:01:14 <aleth> flo-retina: I think so. But as it is done lazily anyway it only really matters for the visible ones (at most dozens)
17:02:22 <aleth> But I could check what the binding state is after display=none, I never did that, so I'm not sure.
17:03:30 <flo-retina> aleth: and how come the nicklist isn't in the same state as display:none when it's collapsed?
17:03:42 <aleth> It's possible they are just marked as dirty in some way
17:04:08 <flo-retina> wouldn't it save memory to do that?
17:04:09 <aleth> flo-retina: I don't know. That's why it was not obvious to me to use this method ;)
17:04:22 <aleth> Save memory to do what?
17:04:24 <flo-retina> (we could even do it from CSS)
17:04:42 <flo-retina> aleth: to display:none the nicklist when it is hidden, so that XBL bindings are garbage collected
17:05:06 <flo-retina> s/garbage collected/destroyed/whatever (yes, that's an invalid sed syntax :-|)
17:05:06 <aleth> Sure, one could do it via CSS just as well.
17:05:29 <aleth> Saves an event handler :)
17:05:34 <aleth> Good idea
17:05:50 <aleth> I'm not sure the memory savings are that important.
17:06:22 <flo-retina> I think they are mostly theoretical ;)
17:06:44 <-- mpmc has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
17:08:26 <aleth> Hmm, the drawback of doing it via CSS would be that the scroll position gets forgotten.
17:09:27 <aleth> That feels wrong to me.
17:09:46 <flo-retina> well.
17:09:53 <flo-retina> The nicklist feels wrong to me ;)
17:10:18 <aleth> Sure... but while we have it lets not make it worse ;)
17:10:19 <flo-retina> it's a waste of space on my screen 90+% of the time, and it's slowing down my conversation window 1% of the time.
17:10:34 * aleth recommends his add-on for the waste of space issue
17:11:25 <aleth> Though it would be nice to come up with an even better UI solution
17:11:31 <flo-retina> could it make the list better to sort by "people I care about"?
17:11:47 <aleth> It would still waste space most of the time
17:12:14 <flo-retina> I guess that would be active nicks + usually active nicks + people I talked to often.
17:12:15 <aleth> But, it might.
17:12:48 <flo-retina> aleth: it's a waste of space most of the time because in channels where it has a scrollbar I don't see any useful info by just looking at it.
17:13:25 <aleth> It's a waste of space most of the time because most of the time you don't actually want to look at it ;)
17:13:39 <flo-retina> Not sure
17:13:45 <aleth> But I agree it would be good to make it more relevant
17:14:06 <flo-retina> when you are talking to people face to face, you usually want to know/look at who you are talking to.
17:14:29 <aleth> It's misleading to think of the active nicks as the only ones listening though
17:14:49 <flo-retina> that's why I said "usually active"
17:15:08 <aleth> Ah.
17:15:11 <flo-retina> you should still assume that you are talking in public
17:15:53 <flo-retina> so you need the people who are likely to answer (in a room that would be who is siting in the front row) and to have an estimate at a glance of the size of the crowd (you can easily get that in a real room)
17:16:04 <aleth> Yes
17:16:11 <aleth> That's a good analogy
17:16:28 <flo-retina> thanks :)
17:16:35 <aleth> Maybe we should do something semi-graphical
17:16:53 <aleth> And that way avoid scrollbars whenever possible 
17:17:01 <flo-retina> I think we could have icons to indicate how crowded the room is
17:17:24 <flo-retina> I usually don't care if there are 27 or 24 people in the room
17:18:45 <flo-retina> ok, what about filling the available space with the "interesting" nicks, and keep the last line for an "XXX more" clickable item that would expand the view to what we currently have?
17:19:34 <aleth> I was thinking of representing the XXX more by dots which would get smaller in log steps as the #participants goes up
17:20:47 <aleth> I agree what you really want is to get a rapid sense of the state of the room
17:21:25 <aleth> I usually have the nicklist hidden (and it reopens on hover). I tend to flick it open when I want to see if someone can be pinged, or just to see if it's been busy ("less gray")
17:21:56 <flo-retina> isn't the tab completion enough for that?
17:22:14 <flo-retina> I would certainly go search for someone in the nicklist (especially if there's a scrollbar) when I can just type the first few letters and tab
17:22:35 <aleth> Usually I use tab complete, but not always
17:22:48 <flo-retina> (deleting the whole content of the textbox is just C-a C-x, so it's easy to get rid of what I've typed if the person isn't here)
17:22:49 <aleth> Not sure why.
17:23:10 <flo-retina> aleth: because you are curious to see if you can reproduce bug 1143 ;)
17:23:18 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1143 nor, --, ---, aleth, ASSI, Collapsed participant list sometimes loses listitems
17:23:27 <aleth> No, that's more why bug 1143 has been annoying me ;)
17:26:48 <aleth> For example right now I am not in the room, according to the nicklist :P
17:27:18 <flo-retina> aleth: I've never seen that bug btw
17:27:27 <flo-retina> aleth: but I guess it's because I also never hide the nicklist
17:27:43 <aleth> Then you'll never see it I think
17:28:20 <aleth> I guess it's just me who likes the nicklist to only appear on hover...
17:28:25 <flo-retina> btw, how come we don't hide it automatically with a media query when it's taking more than half the width of the whole window?
17:28:45 <aleth> When does it do that?
17:29:00 <flo-retina> there's no code to do that
17:29:19 <aleth> Sure, I just meant it's probably not there because you'd have to be using a strange window size
17:29:29 <flo-retina> but there's so much automatic resizing/hiding going on in that conversation window that it's surprising nobody ever did it for the nicklist
17:29:58 <flo-retina> yeah, it's possible people who are using very small IM windows don't care about irc
17:30:09 <aleth> Actually for me it's already there, when I shrink the conv window the nicklist eventually gets narrower
17:30:36 <aleth> Rather done nicely in fact.
17:30:50 <aleth> I wonder if that's a gtk thing.
17:31:18 <flo-retina> maybe one of your add-ons added a flex somewhere
17:32:10 <aleth> Hmm could be, involuntary if so
17:35:36 --> Kaishi has joined #instantbird
17:53:30 --> Mook_as has joined #instantbird
17:55:59 <-- Even1 has quit (Connection reset by peer)
18:03:40 <-- Even2 has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
18:08:08 <-- flo-retina has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
18:21:21 <-- aleth has quit (Input/output error)
18:22:46 --> aleth has joined #instantbird
18:22:47 * ChanServ sets mode +h aleth 
18:27:24 <-- aleth has quit (Quit: Au revoir)
18:27:31 --> aleth has joined #instantbird
18:27:32 * ChanServ sets mode +h aleth 
18:35:40 <aleth> flo: display:none doesn't remove the DOM nodes or the bindings (at least according to DOM inspector). (At least not immediately)
18:36:48 <Mook_as> huh, I'd expect display:none to kill the bindings (but visibility: collapse to keep the bindings).
18:37:55 --> mpmc has joined #instantbird
18:40:39 <aleth> Mook_as: I think it marks them as killable
18:41:03 <aleth> But I don't know how it's done internally
18:45:59 <instantbot> aleth@instantbird.org requested review from florian@instantbird .org for attachment 2165 on bug 1846.
18:46:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1846 min, --, 1.4, aleth, RESO FIXED, Changing the status to available while an IRC account is in the disconnecting state doesn't reconnec
18:48:46 <aleth> Mook_as: My guess is the detachment is not synchronous, just like binding attachment
18:50:30 <aleth> Mook_as: actually, https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Binding_Attachment_and_Detachment under <destructor> implies they don't get detached at all unless you delete or replace the element or its binding.
18:53:10 <Mook_as> that reference is a pack of lies
18:54:20 <aleth> A lot of the XBL reference is kind of contradictory.
18:54:56 <aleth> That bug has been a real pain as a consequence :-/
18:54:57 <Mook_as> yeah, it was started as "what we want to implement", then slowed converted to what's actually implemented... and parts may be spotty.
18:55:20 <Mook_as> does calling .getBoundingClientRect() after setting display:none do anything?
18:56:34 <aleth> you mean, does it lead to a binding attachment?
18:56:57 <aleth> It shouldn't return anything really.
18:57:08 <aleth> s/attachment/detachment
18:57:19 <Mook_as> yeah, if it leads to binding... changes.
18:57:36 * Mook_as usually wants to force attachment, not detachment :p
18:57:47 <aleth> Yup, that's what I've used it for...
18:57:55 <aleth> I think the binding just stays there until it is replaced
18:58:07 <aleth> (or the element is removed)
18:59:47 <Mook_as> could be!
19:00:03 <aleth> But I wouldn't want to depend on it ;)
19:02:28 <-- Kaishi has quit (Quit: Kaishi)
19:11:45 --> mikk_s has joined #instantbird
19:15:41 <-- mikk_s has quit (Quit: Instantbird 1.3 -- http://www.instantbird.com)
19:16:00 --> rosonline has joined #instantbird
19:23:18 --> mikk_s has joined #instantbird
19:24:22 <instantbot> New Core - XMPP bug 1853 filed by rosonline@r7.com.
19:24:25 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1853 nor, --, ---, nobody, UNCO, A message appears when a Facebook friend is trying to call to me
19:25:44 --> Mnyromyr has joined #instantbird
19:25:58 <clokep_work> Thanks rosonline.
19:28:03 <rosonline> clokep_work: You're welcome... I don't have time to file this bug yesterday...
19:30:25 <clokep_work> No problem. :) I don't think there's a rush on it. ;)
19:31:42 <rosonline> my facebook friend was trying to call me (voice call)
19:33:36 <clokep_work> Right.
19:40:12 <-- mikk_s has left #instantbird ()
19:52:05 <-- mpmc has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com)
19:53:13 --> mpmc has joined #instantbird
20:09:46 --> EionRobb has joined #instantbird
20:11:51 --> jb has joined #instantbird
20:12:31 <clokep_work> Instantbird was approved for Symantec's whitelist.
20:20:57 <EionRobb> well done
20:32:19 <-- jb has quit (Ping timeout)
20:59:37 <-- rosonline has quit (Quit: http://www.mibbit.com ajax IRC Client)
21:30:53 --> FireFly_TB has joined #instantbird
21:36:45 <-- skeledrew has quit (Ping timeout)
21:52:24 --> skeledrew has joined #instantbird
22:09:15 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105])
22:21:19 <-- mconley has quit (Ping timeout)
22:34:45 <-- FireFly_TB has quit (Ping timeout)
22:49:09 <-- Even has quit (Input/output error)
23:07:13 <-- meh has quit (Quit: The point is: don't lose your dinosaur.)
23:14:39 --> rosonline has joined #instantbird
23:16:43 <-- mpmc has quit (Connection reset by peer)
23:16:44 <-- aleth has quit (Input/output error)
23:18:22 <-- gg0_ has quit (Quit: leaving)