#instantbird log on 08 20 2012

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)