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)