All times are UTC.
01:24:34 <-- clokep has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 01:34:40 <-- groovecoder has quit (Input/output error) 02:00:33 --> deOmega has joined #instantbird 02:01:26 <-- deOmega has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 02:01:28 --> deOmega has joined #instantbird 02:05:54 <-- deOmega has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 02:05:56 --> deOmega has joined #instantbird 02:10:31 <-- Suiseiseki has quit (Client exited) 02:11:12 --> Suiseiseki has joined #instantbird 02:12:57 <-- Suiseiseki has quit (Connection reset by peer) 02:13:45 --> Suiseiseki has joined #instantbird 02:45:03 <-- deOmega has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 02:45:28 --> deOmega has joined #instantbird 02:48:17 <-- deOmega has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 02:49:02 --> deOmega has joined #instantbird 02:59:56 <instant-buildbot> build #600 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/600 03:01:24 <-- deOmega has quit (Quit: Instantbird 1.2 -- http://www.instantbird.com) 03:10:18 <-- Kaishi has quit (Quit: Kaishi) 04:24:39 --> iLobster has joined #instantbird 04:39:08 <-- iLobster has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 05:07:32 <-- EionRobb has quit (Quit: Leaving.) 05:10:57 <instant-buildbot> build #682 of win32-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/682 05:12:15 <-- Suiseiseki has quit (Client exited) 05:12:48 --> Suiseiseki has joined #instantbird 06:13:18 <instant-buildbot> build #588 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/588 06:51:30 <-- Gizmokid2005 has quit (Ping timeout) 06:57:00 --> Gizmokid2005 has joined #instantbird 07:14:18 --> jb has joined #instantbird 07:49:09 --> Optimizer has joined #instantbird 08:01:13 --> Even has joined #instantbird 08:01:14 * ChanServ sets mode +o Even 08:01:22 <-- Even has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 08:01:27 --> Even has joined #instantbird 08:01:27 * ChanServ sets mode +o Even 08:31:08 <-- gerard-majax_ has quit (Ping timeout) 08:36:05 --> aleth has joined #instantbird 08:36:06 * ChanServ sets mode +h aleth 08:46:42 --> sonny has joined #instantbird 08:49:35 --> chrisccoulson has joined #instantbird 09:14:08 <-- Optimizer has quit (Ping timeout) 09:15:04 <-- jb has quit (Ping timeout) 09:32:09 --> gerard-majax_ has joined #instantbird 09:34:37 --> jb has joined #instantbird 09:38:47 --> Even1 has joined #instantbird 09:44:27 --> Optimizer has joined #instantbird 09:47:04 <-- jb has quit (Quit: jb) 09:47:39 <-- aleth has quit (Quit: Au revoir) 09:57:02 --> flo has joined #instantbird 09:57:02 * ChanServ sets mode +qo flo flo 10:02:39 <-- flo has quit (Input/output error) 10:02:41 --> flo has joined #instantbird 10:02:41 * ChanServ sets mode +qo flo flo 10:12:51 --> jb has joined #instantbird 10:14:41 --> clokep has joined #instantbird 10:14:41 * ChanServ sets mode +o clokep 10:16:34 <-- jb has quit (Connection reset by peer) 10:23:34 <flo> in case anybody here is interested, this is how the message theme proposed in the "Refine IRC theme" tb bug looks for Twitter, IRC and Gtalk: http://imgur.com/a/LzDfD 10:28:31 <clokep> I still think there's a ridiculous amount of wasted space. :-S 10:28:39 <clokep> The Twitter theme looks nice though. 10:29:29 <flo> I don't even know what I think about it any more. 10:30:03 <flo> except that I'm quite frustrated that one week later things are still not resolved/commited, and we are going to have to check-in something for the last tb 15 beta before it's been in even one Daily build. 10:34:03 <clokep> Is Alexander Surkov a Mozilla accessibility guy? 10:34:08 <flo> yes 10:34:19 <clokep> And yes, that is frustrating and I was expecting that bug to be closed weeks ago. :-/ 10:34:51 <flo> initially, I was expecting that it would be fixed in time for Tb*13* 10:35:06 <clokep> Ouch. 10:35:09 <flo> and when I went in vacations, I expected it would be fixed Monday or Tuesday 10:36:49 <flo> I don't even understand why it has the JS of Time Bubbles, but the code of "org.instantbird.minimal.message.style" (I don't even know what that theme is. Is it an add-on on AIO?) 10:37:15 <flo> ah, no, that's what we have on Simple :-S 10:39:34 <clokep> I think it shows a bit of a lack of understanding of the code and what it's doing. 10:40:34 <flo> I also like comment 39 "The only change to previous patch is hiding the interval messages. This includes the lastMessage." 10:42:25 <flo> it looks like all the twitter specific CSS rules are going to be super expensive 10:42:39 <flo> #chat :-moz-any(.outgoing, .incoming):-moz-any([prpl="Twitter"], [prpl="twitter"]) .pseudo 10:45:58 --> ea4eoz has joined #instantbird 10:46:56 --> jb has joined #instantbird 10:48:56 <-- sonny has quit (Ping timeout) 10:58:27 <-- clokep has quit (Ping timeout) 11:14:58 <-- jb has quit (Connection reset by peer) 11:21:34 <-- Optimizer has quit (Ping timeout) 11:48:18 --> clokep_work has joined #instantbird 11:48:18 * ChanServ sets mode +o clokep_work 11:56:42 --> aleth has joined #instantbird 11:56:42 * ChanServ sets mode +h aleth 12:01:11 <-- aleth has quit (Input/output error) 12:01:13 --> aleth has joined #instantbird 12:01:13 * ChanServ sets mode +h aleth 12:02:39 --> jb has joined #instantbird 12:08:57 <clokep_work> FWIW I probably won't be around the second half of this week. Vacation again. :) 12:11:04 <flo> :) 12:11:11 <flo> well, ":)" for you ;) 12:13:20 --> deOmega has joined #instantbird 12:23:04 <clokep_work> Yeah, I'm looking forward to it. 12:23:37 <flo> I can tell you one week is too short for vacations ;) 12:25:13 --> Optimizer has joined #instantbird 12:25:57 <clokep_work> Yeah, and I rarely take a full week. :( 12:35:23 <deOmega> good morning. Shouldn't session restore be on the roadmap? 12:36:28 <deOmega> I know it is an addon now, but assumed it was an addo for testing purposes. no? 12:37:52 <aleth> deOmega: The roadmap isn't complete. 12:38:02 <deOmega> aleth: Ok, thanks 12:38:20 <deOmega> hmm, i think i heard that before. Sorry 12:39:00 <clokep_work> deOmega: The roadmap doesn't really mean much... 12:39:08 <aleth> flo: Why did they special-case twitter? I thought the TB Bubbles had avatars by default anyway... 12:39:40 <deOmega> well, you guys will have less complaints from me I hope :)... I am gonna try to use the stable release versions from now on. 12:39:48 <flo> aleth: they no longer have them :). 12:39:57 <flo> deOmega: why? :) 12:40:15 <aleth> flo: They are going round in circles? ;) 12:40:51 <aleth> flo: I suspect he is escaping the twitter issue... 12:41:37 <aleth> Wait, that is present in 1.2 of course 12:42:53 <aleth> The TB IRC style is really not well suited for the relatively narrow width of the TB conversation binding imho 12:42:54 <flo> would be nice to have steps to reproduce for that twitter issue :-/ 12:43:07 <aleth> But I guess they have a couple of days to tweak it :P 12:44:24 <flo> aleth: today is the very last day to change things in Tb15 12:45:28 <aleth> :-/ 12:45:32 <aleth> flo: I added a link to a twitter page on related issues last week - don't know the twitter code well enough to see if they are relevant though 12:45:52 <clokep_work> aleth: I think I convinced bwinton that he actually wants to special case Twitter and not IRC. :P 12:46:51 <deOmega> flo: just for now. 12:49:03 <deOmega> Seems to me there are hardly any bugs to to report on the nightlies 12:49:22 <deOmega> that used to happen alot before.. now it is very rare 12:49:39 <deOmega> actually, I cannot recall the last time i had to report one 12:49:47 <flo> deOmega: it's because we aren't changing things much just before a release 12:50:52 <clokep_work> Nothing has been changed in a while. :( 12:51:52 <deOmega> ah. That makes sense... because I did not see a difference between 1.2 and 1.3 why it was easy to go back for once to use the regular icon as opposed to teh bomb. 12:52:40 <clokep_work> 1.3 is identical, currently. :) 12:52:49 <deOmega> You know.. i have to admit.. i have been using the beta for so long... seeing the regular icon on my pc seems so strange 12:52:51 <clokep_work> There's a few things that can be checked in and will hopefully be done soon! 12:52:57 <clokep_work> (And I guess we'll update Mozilla soon?) 12:53:46 <deOmega> ok, cool. I know u guys appreciate testers, so will try to come back at some point (if i do not get more senile :) ) 12:54:29 <-- jb has quit (Ping timeout) 12:54:52 <deOmega> note: I have been struggling with my memory lately... so much going on. 12:55:54 <deOmega> well, the past 6 months has gotten worse 13:00:37 <aleth> deOmega: all the best with that :) 13:10:57 <deOmega> aleth: thanks :) 13:23:35 <flo> clokep_work: "irc: Unhandled IRC message: :gravel.mozilla.org 438 fjdslkj fjdskl :Nick change too fast. Please wait 48 seconds" 13:23:51 <clokep_work> flo: Stop changing your nick so fast. :P 13:24:09 <flo> is there an easier way to generate lots of system messages? :) 13:24:19 <aleth> bug 1396 13:24:22 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1396 min, --, ---, nobody, NEW, Unhandled IRC message 438: Nick change too fast 13:24:25 <-- deOmega has quit (Quit: Instantbird 1.2 -- http://www.instantbird.com) 13:24:38 <aleth> flo: Use /topic? 13:24:59 <flo> great idea :) 13:25:06 <flo> hmm, the topic selector is still broken in my tb debug build 13:25:23 * flo looks forward to receiving a laptop that can build current comm-central trunk 13:25:47 <aleth> flo: /help is also a useful one to generate system messages 13:26:40 <flo> right 13:28:59 * clokep_work usually uses /help 13:29:32 <aleth> The /topic is useful because it allows you to generate a system message remotely 13:35:21 * aleth is still dumbstruck by TB folks landing the default message style a day before release 13:36:41 <aleth> It's not like we didn't find some last minute nits in Bubbles before 1.2 ;) 13:39:35 <flo> aleth: it was in code that we have had for months though ;) 13:40:14 <aleth> flo: Yes, that's why... imagine if we had just landed major changes a day before release... 13:40:32 <flo> aleth: so at least you understand why I'm frustrated by this ;) 13:41:43 <aleth> Yes - I don't quite understand why you seem to have a variant of this every single TB release train. Unless it's precisely that TB is in a hurry to move away from rapid releases.... 14:04:50 <flo> hmm, is there a way to display context messages in Tb? 14:08:59 --> wnayes has joined #instantbird 14:26:23 <-- meh has quit (Ping timeout) 14:29:44 * clokep_work doesn't know. 14:33:19 <flo> I found one 14:33:25 <flo> redisplaying a conversation in another window 14:37:58 --> deOmega has joined #instantbird 14:38:58 <deOmega> hey guys... as clokep indicated as a possibility.. there is indeed an obvious difference in the stream between the oteh rmessenger i am using and what IB is 14:39:19 <deOmega> whatever or however IB is configured... it gets its updates faster 14:39:22 <deOmega> more realtime 14:39:29 <deOmega> when it is working anywya 14:40:23 <deOmega> I know this because i have them both running twitter simultaneously 14:40:39 <flo> that doesn't seem like a bug ;) 14:41:28 <deOmega> well, the bug is that the feed stops. BUt whatever the configuration is, I suppose that is what I would want.. as long as it works consistently 14:42:41 <flo> deOmega: Instantbird uses the user stream from twitter (that is, we keep a persistent connection to the twitter server, and twitter sends new tweets to us as soon as they are available). I suspect your other client is using the older method of asking the twitter server if there are new tweets every few seconds or minutes. 14:43:09 <deOmega> ah! 14:43:34 <deOmega> that would make sense in terms of the delays 14:43:51 <flo> deOmega: and we suspect the bug you encounter is the twitter server no longer sending us updates through that persistent connection, but without closing the connection (when the connection is closed we start a new one automatically) 14:44:44 <deOmega> making sense again (and so, no workaround?) 14:45:01 <clokep_work> flo: Is there any "ping" protocol as part of Twitter? (I.e., we haven't received a tweet in xxx minutes, ping the server to ensure the connection is open) 14:45:09 <deOmega> i suppose the workaround would be to go with what the other service uses? 14:45:24 <flo> clokep_work: no 14:45:27 <deOmega> ignore me, please continue 14:45:50 <flo> clokep_work: the twitter server usually sends some whitespace through the connection every 50s to keep it alive. 14:45:52 <deOmega> Oh, thought u guys were gonna get into an intricate tech dialog :) 14:46:27 <flo> clokep_work: so I'm wondering if we should decide the connection is dead after 2 minutes without receiving anything from the connection. 14:47:00 <clokep_work> flo: That seems reasonable, yes. Does XmlHttpRequest have a timeout on it? (Sockets do...) 14:47:02 <deOmega> yes! 14:47:02 <flo> clokep_work: but that "server will send some whitespace every 50s if there's no new tweet to send" behavior isn't documented anywhere, it's just what I've observed. So I'm quite reluctant to code something expecting it. 14:48:22 <-- Suiseiseki has quit (Client exited) 14:48:22 <clokep_work> Oh boo. :( 14:48:27 <flo> clokep_work: hmm... actually, it's possible the bug appeared when we switched to receiving chunked data instead of a regular XHR. Maybe the XHR timeout is broken in that case? 14:48:38 <clokep_work> flo: That's what I was wondering too. 14:48:53 <flo> in any case, it would really help to have a way to reproduce 14:49:02 --> Suiseiseki has joined #instantbird 14:49:19 * clokep_work hasn't tried just adding a ton of search words yet. 14:49:22 <clokep_work> I should try that tonight. 14:49:38 <flo> clokep_work: or maybe we aren't notified (either not notified at all, or not notified as we expect) when the socket is closed now that we request chuncked data? 14:49:47 <flo> clokep_work: #fail is enough 14:50:41 <clokep_work> wnayes: "Looks like I will need to have my completed code ready by around noon tomorrow" so do you need anything from us in the next two hours? :) 14:50:47 --> meh has joined #instantbird 14:51:17 <flo> isn't the code submission deadline August 31st? :) 14:51:49 <clokep_work> flo: #fail, of course. :) 14:51:54 * deOmega never thought twitter feeds would become such an important aspect.. but everyone/company disseminates information there.. so i just follow the way I do my news feeds through other platforms. 14:51:55 <clokep_work> Maybe we aren't anymore, who knows. (Mozbug?) 14:52:49 <wnayes> clokep_work: I don't think so, everything seems to be working well enough for a review at some point. 14:53:05 <clokep_work> Excellent. :) 14:53:17 <clokep_work> I assume you go back to school this weekend? 14:53:53 <flo> wnayes: I haven't read any of the IRC logs after returning from vacations. Is there anything you said last week that I should have read? :) 14:54:13 <wnayes> flo: From what I read, they want the code done now before the final review (changes can probably be made but not submitted) 14:55:13 <wnayes> clokep_work: In a couple of weeks, so I could have some time to look into improving it before then. 14:55:55 <deOmega> flo: I will send my wife to massage your neck while you recode :) 14:56:16 <dew> haha 14:56:36 <-- flo has quit (Ping timeout) 15:00:17 <deOmega> ha! that chased him away? My wife is attractive! 15:02:13 <clokep_work> wnayes: Ah OK. :) Not really why I was asking, was just curious. 15:02:20 --> flo has joined #instantbird 15:02:20 * ChanServ sets mode +qo flo flo 15:10:32 <-- Gizmokid2005 has quit (Ping timeout) 15:10:55 --> myk has joined #instantbird 15:11:01 --> Gizmokid2005 has joined #instantbird 15:11:23 <wnayes> flo: Last week was mainly getting the UI (hopefully) bug free and usable. I'm not sure what I need to all do for code submission but I'll probably end up writing something on the current state of the code and get some updated UI images. 15:27:22 <flo> wnayes: hey https://bugzilla.mozilla.org/show_bug.cgi?id=781956 is fixed (I wasn't cc'ed), congrats! :) 15:27:42 <flo> apparently my choice of reviewer was correct :) 15:29:55 <wnayes> flo: Yeah, thanks for finding a reviewer! I didn't know who to select. :) 15:30:19 <flo> that part is difficult for newcomers ;) 15:31:30 <flo> don't hesitate to ask for help (here if it's related to instantbird or in #developers for any other Mozilla patch) when picking a reviewer for a code area you don't know yet :) 15:32:27 <clokep_work> flo: I had Will add that patch to tools/patches, is that the appropriate thing to do instead of some other work around? 15:32:53 <flo> clokep_work: it's correct, especially if it's already upstreamed :) 15:33:33 <flo> ensure there's the bmo bug number in the patch name, so that it's trivial to see why it doesn't apply any more when updating Mozilla 15:38:11 <-- Optimizer has quit (Ping timeout) 15:38:57 <clokep_work> wnayes: ^ 15:40:23 <wnayes> Yeah, I included the bug number since most of the other patches did as well :). Looks like it will hit release in Moz17, so a couple of months from now? 15:41:07 <flo> yeah, in November. 15:55:45 <-- myk has quit (Input/output error) 15:55:55 --> myk has joined #instantbird 15:57:08 --> Optimizer has joined #instantbird 15:57:27 --> wesj has joined #instantbird 16:06:47 <-- aleth has quit (Quit: Au revoir) 16:07:07 --> aleth has joined #instantbird 16:07:07 * ChanServ sets mode +h aleth 16:10:03 <-- flo has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 16:18:36 --> igorko has joined #instantbird 16:23:05 <-- deOmega has quit (Quit: Instantbird 1.2 -- http://www.instantbird.com) 16:38:12 --> flo has joined #instantbird 16:38:13 * ChanServ sets mode +qo flo flo 16:45:32 --> Mook has joined #instantbird 16:55:40 <-- meh has quit (Ping timeout) 17:01:14 <-- Suiseiseki has quit (Connection reset by peer) 17:01:51 --> Suiseiseki has joined #instantbird 17:25:02 --> meh has joined #instantbird 17:30:50 <instantbot> wnayes@gmail.com cancelled feedback?(florian@instantbi rd.org) for attachment 1738 on bug 1495. 17:30:51 <instantbot> wnayes@gmail.com requested review from florian@instantbird .org for attachment 1814 on bug 1495. 17:30:53 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1495 enh, --, ---, wnayes, ASSI, Create an account import wizard - GSoC 2012 17:32:16 <wnayes> Hopefully we can look over this soon :)! Some friends are visiting now so I have to go, but will be back later. 17:33:05 <-- gerard-majax_ has quit (Ping timeout) 17:51:35 <aleth> That's quite the patch wnayes! :) 18:01:20 <-- myk has quit (Ping timeout) 18:03:06 --> myk has joined #instantbird 18:13:07 <clokep_work> aleth: You going to review it? ;) 18:16:29 --> gerard-majax_ has joined #instantbird 18:32:46 --> gerard-majax__ has joined #instantbird 18:32:51 <-- gerard-majax_ has quit (Quit: Ex-Chat) 19:09:37 <clokep_work> Congrats. ;) Looks like the new theme will land in time. :P 19:09:51 <flo> yeah... 19:19:35 <-- igorko has quit (Client exited) 19:20:26 <-- chrisccoulson has quit (Ping timeout) 19:21:26 <aleth> Oh, they decided to strip out all the time bubbles code? 19:21:50 <aleth> That'll be even more distinctive from IB at least ;) 19:22:40 <clokep_work> "they" being flo, I think. 19:23:13 <aleth> Ah, I thought it was the thunderbird UX guys working on this... 19:23:30 <flo> clokep_work: no, I did the code change, but apparently they decided it before, without any discussion that I could see, and were just thinking of hiding it with CSS 19:25:33 <clokep_work> flo: Right, well I meant you did the stripping out. 19:25:46 <flo> they probably never read the time bubbles blog post, and just thought it was duplicated information, now that all the timestamps were displayed, which is obviously much better as it gives more information to the user :-P 19:26:18 <clokep_work> Eh, well...we don't have to use it so. ;) 19:26:42 <aleth> It probably looked strange after hiding the bubbles in Bubbles ;) 19:26:46 <aleth> Why not just remove the hr elements rather than |hr{display: none !important;}| ? 19:30:43 <flo> aleth: because the JS code from bubbles hides/shows them when clicking the "+"/"-" signs, and the JS wouldn't work any more without them 19:31:10 <flo> if we were serious about this code, we would rewrite that part of the JS code 19:31:17 <flo> but not the last day before the release ;) 19:31:19 <aleth> Right. 19:37:45 --> chrisccoulson has joined #instantbird 19:38:43 --> Mnyromyr has joined #instantbird 19:45:24 * ChanServ sets mode -b *!DGMurdockI@*.hsd1.il.comcast.net 19:45:24 * ChanServ sets mode -b hasOwnProperty!*@* 19:57:04 <aleth> ^^ clokep_work !? 19:57:27 <dew> what happened 19:58:05 <clokep_work> aleth: Hmm? 19:58:11 <clokep_work> flo: Apparently we did have another ban... 19:58:26 <aleth> clokep_work: "mode (hasOwnProperty!*@* -b) by ChanServ." is that our code or...? 19:58:42 * clokep_work sets mode +b hasOwnProperty!*@* 19:58:50 <clokep_work> aleth: I'm not sure what you mean? 19:58:59 <clokep_work> We ban the nick "hasOwnProperty" from joining. 19:59:12 <aleth> oh, OK. 20:01:06 <aleth> That makes sense ;) It just looked a bit like code ending up in the wrong place... 20:02:57 <clokep_work> Nope. :) 20:07:09 <-- meh has quit (Quit: Lost terminal) 20:07:17 --> meh has joined #instantbird 20:09:14 <flo> clokep_work: do we still need that btw? 20:09:20 <flo> isn't the bug fixed in 1.2? 20:09:40 <clokep_work> If it was fixed in 1.1 we can get rid of it most likely. 20:09:50 <clokep_work> It was never an issue on IRC anyway, just Twitter. 20:10:23 <clokep_work> (So no, we don't really need it.) 20:10:40 <flo> "It was never an issue on IRC anyway" uh? 20:10:50 <flo> wasn't it breaking the whole conversation binding? 20:11:21 <clokep_work> Ohhh, right. It was breaking the binding, but not the protocol (libpurple didn't care obviously). 20:11:35 <clokep_work> I forgot we used it in the binding too. :) 20:11:45 <clokep_work> I think if it was fixed for 1.1 we can get rid of it, yeah. 20:12:02 <flo> not sure if it was 1.1 or 1.2 20:12:24 <flo> doesn't hurt to keep that nick banned anyway 20:12:33 <flo> have we also banned __proto__ just for good measure? :-D 20:12:45 <flo> (I think that one only broke ChatZilla though :-D) 20:13:23 * clokep_work sets mode +b __proto__!*@* 20:13:31 <clokep_work> We have now. ;) 20:15:43 <instantbot> New Core - IRC bug 1655 filed by clokep@gmail.com. 20:15:46 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1655 enh, --, ---, nobody, NEW, Unhandled IRC messages around bans 20:21:01 <clokep_work> Yay for more unhandled stuff. ;) 20:21:17 <clokep_work> I dislike how (for only bans AFAIK) the mode commands takes an extra parameter... 20:21:42 <aleth> I dislike the mode command ;) 20:22:43 --> igorko has joined #instantbird 20:22:45 <aleth> Should we put that special case in the /help mode btw? 20:22:46 <flo> I dislike lots of IRC commands :-P 20:23:57 <clokep_work> aleth: I'd rather a /ban and /unban command. 20:24:09 <aleth> clokep_work: Good idea. 20:26:20 <clokep_work> :) 20:27:36 <flo> the great thing about the ban command as described in most places is that if you omit the nick argument, you ban yourself from the current room, or all rooms where you currently are 20:27:51 <flo> sounds like a super useful feature to make easily accessible... 20:31:45 <dew> lul 20:31:52 <dew> that's awesome 20:33:53 <clokep_work> Right, so we could make /ban fail without a nick. :) 20:33:59 <clokep_work> (Well a hostmask / whatever.) 20:36:37 <flo> clokep_work: I hope you would r- an implementation that bans the user by default :) 20:36:53 <flo> even if it's the "standard behavior" :-D 20:38:27 <dew> yeah that's dumb standard behavior 20:38:37 <dew> needs to have something like /ban --force ;d 20:38:44 <clokep_work> flo: I would pull out my banhammer and r- it... 20:38:54 <dew> kind of like in the *nix world where you're likely to f something up 20:39:01 <dew> you just "force" it ;) 20:39:04 <clokep_work> dew: It's a totally unnecessary and unexpected behavior that just doesn't need to be supported IMO. 20:39:13 <dew> yeah you're right 20:39:26 <dew> but I'm saying why would they make that in the standard 20:39:31 <dew> makes no sense to me at all 20:39:57 <douglaswth> from /help ban in irssi: "If no arguments are given the current bans in this channel are displayed." 20:40:20 <dew> yeah same behavior in mIRC I thought 20:40:48 <dew> er maybe it was my NNscript that did that? 20:40:56 <dew> just /ban yields an error message 20:41:46 <flo> douglaswth: I think it's the help of the chanserv BAN command that I read :) 20:42:31 <flo> "21:36:37 - ChanServ: Syntax: BAN [#channel [nick [reason]]] Bans a selected nick on a channel. If nick is not given, it will ban you. If channel and nick are not given, it will ban you on all channels you're on [â¦]" 20:44:25 <clokep_work> http://www.anope.org/docgen/1.8/en_us/ChanServ.html also works... 20:44:40 <clokep_work> But yeah, it's the ChanServ command, we would want to implement the mode stuff directly for a ban command. 20:49:43 <-- igorko has quit (Quit: Instantbird 1.2 -- http://www.instantbird.com) 20:56:16 <-- clokep_work has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 20:57:27 <-- Optimizer has quit (Ping timeout) 21:20:07 <-- myk has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- Suiseiseki has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- Mook has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- wesj has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- Gizmokid2005 has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- wnayes has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- dew has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- skeledrew has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- micahg has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- douglaswth has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- spiffytech has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- harisund has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:07 <-- ivan has quit (gravel.mozilla.org concrete.mozilla.org) 21:20:38 --> myk has joined #instantbird 21:20:38 --> Suiseiseki has joined #instantbird 21:20:38 --> Mook has joined #instantbird 21:20:38 --> wesj has joined #instantbird 21:20:38 --> Gizmokid2005 has joined #instantbird 21:20:38 --> wnayes has joined #instantbird 21:20:38 --> dew has joined #instantbird 21:20:38 --> skeledrew has joined #instantbird 21:20:38 --> micahg has joined #instantbird 21:20:38 --> douglaswth has joined #instantbird 21:20:38 --> spiffytech has joined #instantbird 21:20:38 --> harisund has joined #instantbird 21:20:38 --> ivan has joined #instantbird 21:21:08 --> EionRobb has joined #instantbird 21:21:21 --> Kaishi has joined #instantbird 21:21:40 <-- micahg has quit (Ping timeout) 21:21:45 <wnayes> Hmm, "4:20:55 PM - mode (flo +qohovvh) by (null)." 21:26:55 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105]) 21:31:20 <aleth> wnayes: What happens if I run the importer after I have already created an account that matches one of the importable ones? Are the logs still imported and "merged"? 21:31:32 --> micahg has joined #instantbird 21:32:22 <aleth> Possible scenarios: 1) I decide not to import on first startup, as I am "just trying out IB". I add some accounts for testing. Later I decide to stay with IB and so do the importing. 21:32:58 <wnayes> aleth: The UI filters out accounts you already have created. 21:33:27 <aleth> 2) I have previously switched from e.g. empathy to Pidgin and the same account exists in both. I'd expect the importer to merge the logs and create the account. But it seems it will only import one or the other. 21:34:01 <aleth> Yes, my questions is whether this is always the desired behaviour... 21:37:11 <wnayes> I think that the cases you list are reasonable, as of now the behavior is really transparent and design to work without user intervention. 21:37:47 <wnayes> Merging the logs for two accounts might be as simple as copying the folders together, as two clients would likely not have identical copies. 21:37:53 <aleth> Sure :) I'm only thinking aloud. I wonder if one could solve this without requiring any user intervention 21:39:02 <wnayes> Addons could definitely have a role in providing more "advanced" use cases too. 21:39:10 <aleth> The only real stumbling block I see as far as logs are concerned would be if some other client has an importer as good as yours ;) that can handle log importing... 21:40:54 <aleth> Then you might end up with multiple copies of the same conversation or such 21:41:03 <aleth> "Merging the logs for two accounts might be as simple as copying the folders together, as two clients would likely not have identical copies." -- But can I even import both if I have used aleth@jabber.org with both clients? 21:41:58 <aleth> (I think case 2) is the more important one to think about) 21:42:21 <wnayes> I had it in the back of my mind to create an addon at some point that exposes control to the importing features. 21:43:30 <aleth> Would it make sense as a default to "merge" accounts (i.e. combine logs, use the settings from the most recent one) that definitely match? 21:44:21 <wnayes> When deleting from IB, logs are not lost. So as it stands now one account could be imported, deleted, and then the second imported. Not exactly ideal but it could work :) 21:46:43 <aleth> Neat trick ;) If it works, you could almost simply import all matching accounts, in chronologically ascending order :P 21:46:45 <-- micahg has quit (Client exited) 21:49:15 --> micahg has joined #instantbird 21:50:20 <wnayes> Having a "merge" option might not take that much modification, depends on how complex of a merge is desired (comparing message-by-message for duplicates would be difficult, and then there's the issue with dates not always being fully provided by other clients) 21:50:26 <flo> do you have code to parse Pidgin's plain text logs now? :) 21:51:56 <wnayes> flo: Messages are distinguished between incoming/outgoing and system for Pidgin plaintext so far. 21:52:49 <wnayes> But there's the issue of parsing the types of messages within those (mode,part,quit,etc.) when locales can vary. 21:53:50 <wnayes> mIRC being English only made the log parsing a bit more accurate. 21:54:29 * aleth is looking forward to importing some ancient logs he has floating around somewhere :) 21:58:05 <flo> wnayes: how do you know if a message is incoming or outgoing? :) 22:00:28 <wnayes> flo: The username is stored in a header line in the log files, so just a comparison to that. Maybe slightly more accurate than using the account name, but username changes (in IRC only?) might throw things off. 22:03:23 <flo> usernames are likely to change on most protocols 22:03:34 <flo> or just when the user sets a local alias for the contact 22:04:15 <aleth> Getting it right most of the time is still better than nothing... 22:05:15 <flo> aleth: if it doesn't work as soon as the display name isn't the username, it will rarely work for Gtalk/facebook chat/MSN, so I'm not sure "most of the time" is accurate here ;) 22:05:27 <aleth> flo: I was just going to ask about XMPP ;) 22:07:26 <flo> the incoming/outgoing distinction may not be very important though. 22:07:38 <aleth> It's just a colour, ultimately. 22:08:30 <wnayes> I've never been much of an alias user, so that was not on my mind. Pidgin alias' are easy enough to parse though... 22:08:38 <aleth> Though I'm not sure what message styles do when you have different outgoing participants but isChat=false 22:08:59 <aleth> wnayes: It's because XMPP usernames by default are very long and ugly 22:09:33 <aleth> (at least they can be) 22:14:14 <wnayes> I'll need to start a list of these thoughts/features so I don't forget :). But at this point I'm more concerned about getting the API right before fine-tuning per client. 22:25:59 <flo> Good night :) 22:31:35 <wnayes> flo: Good night! I'll get going on the GSoC final evaluation tomorrow if it is available :) 23:22:14 <-- wnayes has quit (Quit: Instantbird 1.3a1pre -- http://www.instantbird.com) 23:42:09 <-- aleth has quit (Quit: Au revoir)