#instantbird log on 06 26 2013

All times are UTC.

00:44:56 <-- mconley has quit (Input/output error)
00:54:10 --> atuljangra has joined #instantbird
01:00:27 <atuljangra> While connecting facebook, if I put my email address in place of username, the accounts window shows error. Is there a way to change the username,  without creating a new account. I guess not, but why so? Just curious.
01:05:24 --> clokep has joined #instantbird
01:05:24 * ChanServ sets mode +o clokep 
01:06:08 <clokep> atuljangra: THere's multiple things you could be asking "why" about in that question.
01:07:10 <atuljangra> clokep: heh yes.
01:07:25 <atuljangra> so first of all, can we change the username,  without creating a new account?
01:09:07 <clokep> atuljangra: bug 429 I think is what you're asking.
01:09:09 <clokep> atuljangra: No.
01:09:20 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=429 enh, --, ---, nobody, NEW, Rename accounts (i.e. change the username)
01:09:34 <atuljangra> Yes :-) Thanks :)
01:11:31 <clokep> atuljangra: We could get it to work w/ emails, by the way, if we implemented their special oauth thing, I think?
01:13:48 <atuljangra> for facebook?
01:14:44 <clokep> Yes.
01:15:32 <atuljangra> yes, I guess we can get it to work that ways. But still, if bug 429 is fixed, then that would be best :)
01:15:47 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=429 enh, --, ---, nobody, NEW, Rename accounts (i.e. change the username)
01:17:12 <clokep> Sure, it's not easy.
01:17:43 <atuljangra> yes. Agreed.
01:18:15 <clokep> It involves touching the databases.
01:19:19 <atuljangra> yes, we actually need to go to the database where we store the accounts info, and then edit them somehow. After that, we need to try to connect to this *new* account.
01:20:32 --> jb has joined #instantbird
01:20:41 <clokep> Sure.
01:21:00 <-- Mook_as has quit (Quit: Mook_as)
01:21:54 <clokep> atuljangra: No one is working on it.
01:22:27 <atuljangra> clokep: oh okay. I've kept it in my todo list after filelink project is over.
01:23:36 <clokep> OK.
01:27:53 <atuljangra> clokep: is this.name here: http://lxr.instantbird.org/instantbird/source/chat/protocols/facebook/facebook.js#24 some sort of number? Like -100000000012131
01:28:40 <clokep> atuljangra: When we receive buddy lists, yes.
01:28:43 <clokep> What are you trying to figure out?
01:30:02 <atuljangra> Nothing, I was just looking at the whole codebase, just for fun. :)
01:30:27 <clokep> Ah, OK.
01:33:20 <-- rosonline has quit (Client exited)
01:33:40 <-- jb has quit (Quit: jb)
01:47:56 <-- dionisos has quit (Ping timeout)
01:53:30 <-- Nirgali1 has quit (Ping timeout)
02:05:47 <-- clokep has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
02:09:38 <-- mpmc has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
02:10:10 --> Nirgali has joined #instantbird
02:14:16 <-- wnayes has quit (Quit: wnayes)
02:55:28 --> mconley has joined #instantbird
02:55:46 --> Mook has joined #instantbird
03:07:37 <instant-buildbot> build #891 of linux-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/891
03:22:56 <-- mconley has quit (Input/output error)
03:30:13 --> mconley has joined #instantbird
03:31:17 <instant-buildbot> build #883 of macosx-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/883
03:33:35 <-- mconley has quit (Input/output error)
04:24:45 --> Optimizer has joined #instantbird
04:33:50 <-- Optimizer has quit (Ping timeout)
04:57:58 <-- Mook has quit (Quit: Mook)
05:08:11 <-- atuljangra has quit (Ping timeout)
05:28:05 <-- chrisccoulson has quit (Ping timeout)
05:28:27 --> chrisccoulson_ has joined #instantbird
05:31:01 <-- Nirgali has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
05:33:41 <-- chrisccoulson_ has quit (Ping timeout)
05:34:10 <-- EionRobb has quit (Ping timeout)
05:36:26 --> EionRobb has joined #instantbird
05:40:54 <-- EionRobb has quit (Ping timeout)
05:44:23 --> EionRobb has joined #instantbird
05:45:42 <-- EionRobb has quit (Quit: Leaving.)
05:46:54 --> EionRobb has joined #instantbird
05:48:36 <-- EionRobb has quit (Ping timeout)
05:57:12 <instant-buildbot> build #986 of win32-nightly-default is complete: Success [build successful]  Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/986
06:31:04 --> chrisccoulson has joined #instantbird
06:39:34 --> Optimizer has joined #instantbird
07:31:50 --> eson57 has joined #instantbird
07:33:00 <eson57> Hi guys! Translation builder is down?
08:06:02 --> gerard-majax_ has joined #instantbird
08:11:08 --> EionRobb has joined #instantbird
08:26:24 --> Mic has joined #instantbird
08:26:24 * ChanServ sets mode +h Mic 
08:28:32 <Mic> eson57: I don't know.
08:28:52 <Mic> Even: can you help eson57 with his question?
08:38:58 <eson57> Hi Mic! No hurry... I just like to test new translations.
08:50:23 <-- eson57 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
08:51:17 --> qlum has joined #instantbird
08:51:39 <-- qlum has quit (Quit: Getting the <censored> out.)
08:51:40 --> qlum has joined #instantbird
08:51:47 <-- qlum has quit (Quit: qlum)
08:51:48 --> qlum has joined #instantbird
08:52:00 <-- qlum has quit (Quit: Getting the <censored> out.)
08:52:37 --> qlum has joined #instantbird
08:53:00 <-- qlum has quit (Quit: Getting the <censored> out.)
08:53:03 --> qlum has joined #instantbird
08:53:11 <-- qlum has quit (Quit: qlum)
08:53:12 --> qlum has joined #instantbird
08:53:17 <-- qlum has quit (Quit: qlum)
08:53:54 --> qlum has joined #instantbird
08:55:14 <qlum> I don't know what you guys did in the for last nightly build but it utterly broke the vertical tabs addon. 
08:55:38 --> aleth has joined #instantbird
08:55:38 * ChanServ sets mode +h aleth 
09:01:07 <Mic> qlum: we've seen extensive changes to the tabbrowser which is hosting the tabs. The changes were necessary to allow a GSoC project to add tabs containing other things than just conversations.
09:01:34 <qlum> okay
09:02:07 <Mic> clokep: the vertical tabs seems to be broken by the tabbrowser changes, maybe you can have a look?
09:02:14 <Mic> *vertical tabs add-on
09:03:36 <qlum> anyway it's luckily not that big a deal for me now as I recently cut back quite a bit on the amount of stuff I am connected to
09:10:03 * aleth wonders if Mic agrees with his comment on bug 2015
09:10:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2015 enh, --, ---, nhnt11, NEW, Display buddy list in a tab.
09:11:41 <aleth> I'm not sure if the goal is to just land something quickly or to plan ahead a bit more first.
09:27:19 --> flo-retina has joined #instantbird
09:27:19 * ChanServ sets mode +qo flo-retina flo-retina 
10:05:00 --> clokep has joined #instantbird
10:05:01 * ChanServ sets mode +o clokep 
10:10:13 <-- gerard-majax_ has quit (Ping timeout)
10:20:22 <Mic> aleth: I assumed that the buddy list tab would morph into the Awesometab with time, so it's not something completely separate in my opinion (i.e. I think your concerns are valid).
10:20:56 * flo-retina is looking forward to webrtc in Ib :)
10:21:27 <aleth> moz22?
10:22:07 <Mic> flo requested it to be spun off into a separate bug so it can be "FIXED" when it lands, so he might have a different opinion on this. He requested to only create and show the contacts matching the filter too, iirc.
10:22:53 <flo-retina> Mic: basically, I requested a separate bug for what I think is the first milestone
10:23:03 * clokep mumbles.
10:23:10 <clokep> Updating Vertical Tabs is always a chore...
10:23:31 <flo-retina> Mic: the first milestone is (if we agreed and expressed ourselves clearly) the awesometab with only info from the contact list, and without smart sorting.
10:24:27 <flo-retina> Mic: so I would say, we just display enough contacts to fill the window from top to bottom (and don't need to support scrolling), and if the user types something in the search box, we update the display to include only contacts matching the search term.
10:24:29 <Mic> Yes, that's what I was thinking at least and meant with "would morph into the awesometab with time".
10:24:33 <flo-retina> does this match your understanding?
10:24:42 <Mic> Yes, exactly.
10:25:42 <flo-retina> the next milestone will then be either to support MUCs (with /list support for IRC), or to start thinking about sorting so that the top 6 contacts displayed are the ones the user cares about
10:28:08 <flo-retina> hmm, I wonder if the issue about freezing when an account signs off isn't just that he tries to update the list for each contact that has changed status. If this is the problem, just using an executeSoon call would fix it (as the list of contacts would only be updated once if all contacts are marked offline at once).
10:28:37 <flo-retina> Even if we display only 6 contacts, we don't want to redisplay the list 6 times when an account is disconnected.
10:28:50 <aleth> I think it's quite possibly due to doing things with DOM elements whose binding has never got attached.
10:29:04 <flo-retina> I guess someone needs to look at the patch
10:29:25 <aleth> If he doesn't create DOM elements for stuff that is never visible that will not happen ;)
10:29:26 <flo-retina> I hope we'll checkin the /about patch soon, so that we can move on
10:29:39 <aleth> Hopefully that can land today.
10:29:41 <Mic> flo-retina: I suggested (in the beginning) to collect data from either the logs or from volunteers that let him collect it (in an anonymized way).to develop his algorithm based on it.
10:29:54 <Mic> (And not assumptions about recency and frequency)
10:29:56 <flo-retina> aleth: your context menu patch is also close to the top of my review-priority list (as it's a feature I really want), but I'm not sure when I'll have time for it
10:30:16 <flo-retina> maybe Mic wants to f? it? (if Mic has time for it sooner than I do)
10:30:26 <flo-retina> hmm, I may have 1 hour for it tomorrow morning in the TGV to Paris
10:30:53 <flo-retina> Mic: which data would you collect?
10:30:53 <aleth> flo-retina: You can consider the present iteration between a f? and a r?. It works well, but hopefully you will have some ideas for improvements ;)
10:31:02 --> gerard-majax_ has joined #instantbird
10:31:07 <Mic> sorry, gtg
10:31:21 <flo-retina> aleth: ok
10:31:35 <flo-retina> aleth: I was confused by such a large patch for something I expected to be simple
10:31:42 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com)
10:31:53 <flo-retina> especially, I don't fully see how tag stuff relate to showing something above the MUCs participants
10:31:58 <aleth> flo-retina: It's not complicated really. It just moves code around.
10:32:14 <flo-retina> aleth: yeah, I guess it's mostly code moving around
10:32:20 <aleth> flo-retina: The tag stuff is for the default "Add contact" nick context menu entry
10:32:43 <aleth> Just to avoid duplicating that code from the blist.
10:32:54 <flo-retina> Why do we need that?
10:33:02 <flo-retina> can't that just popup the awful add contact dialog?
10:33:12 <aleth> I think your question answers itself :P
10:33:25 <flo-retina> no it doesn't
10:33:33 <aleth> Plus it makes no sense to popup that dialog when we already know the name.
10:33:35 <flo-retina> I don't think we should have several different awful UIs for adding contacts
10:33:47 <aleth> It's not a new UI.
10:33:59 <flo-retina> hmm, you've got a point, we already know the name and account
10:34:38 <flo-retina> alright, I need to test it before knowing how I really feel about that UI
10:34:41 <aleth> The tag menu has an awful dialog for the case when you want to create a new tag, I didn't change that ;)
10:35:07 <flo-retina> (from thinking about it theoretically, it seems broken, but maybe it's the best we can do within a reasonable amount of time)
10:35:32 <flo-retina> dialogs suck :(
10:36:37 <flo-retina> (completely unrelated) I wonder what system we could use to indicate that some bugs are really wanted
10:36:45 <aleth> I'm not completely happy with it either. To get a quick idea of it I'd say just apply the patch and see what it looks like.
10:36:57 <flo-retina> aleth: that's the plan ;)
10:37:33 <flo-retina> I think some projects have "bounties" associated to their bug trackers.
10:37:53 <aleth> Points :P
10:37:58 <flo-retina> I would happily offer a few dollars for something like bug 2006; but not an amount significant enough to motivate anybody to actually do it.
10:38:01 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2006 enh, --, ---, nobody, NEW, The /invite command should support taking more than one nick as parameter
10:38:07 <aleth> It would be nice to be able to 'star' bugs for sure
10:38:28 <flo-retina> so I could possibly promise fast reviews.
10:38:31 <aleth> I suppose the votes system was meant to do that
10:38:42 <flo-retina> except that's in a part of the code where I don't do reviews any more
10:40:12 <flo-retina> aleth: it was likely meant for that yes. But I don't think it matters to potential contributors that N random people like the bug; it's more important to know that someone in a position of deciding to include the patch wants the feature very much.
10:40:45 <aleth> flo-retina: Well, for example I had no idea that particular bug was more than a nice-to-have syntax-isn't-optimal
10:41:09 <aleth> Because I don't use /invite much I guess ;)
10:41:16 <flo-retina> aleth: I don't either
10:41:27 <flo-retina> but last time I tried the result was completely unexpected
10:42:05 <flo-retina> I typed "/invite cloke_p Mi_c" and the result was a private conversation with Mic opening, with a nonsensical system message insulting me for not RTFM'ing.
10:42:24 <aleth> That would be unexpected :P
10:43:36 <flo-retina> but yeah, it's not something really important. Just itches I would happily scratch if I didn't spend all my ib-time doing reviews.
10:55:34 <instantbot> clokep@gmail.com requested review from aleth@instantbird.o rg for attachment 2519 on bug 2006.
10:55:37 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2006 enh, --, ---, clokep, ASSI, The /invite command should support taking more than one nick as parameter
10:55:40 * clokep awaits his check.
10:55:47 <aleth> Haha :D
10:56:10 <flo-retina> see, some people are talking a lot; others are coding ;)
10:57:11 <flo-retina> clokep: should "Invite someone" be changed to "Invite one or more nick" ? (or "nicks"?)
10:57:28 <clokep> flo-retina: Probably. I was more concerned about a code review.
10:57:34 <clokep> I'm running late now though, so comments in the bug please!
10:57:38 <flo-retina> is it possible to invite someone to a channel where you aren't yourself?
10:57:43 <flo-retina> clokep: ok :)
10:57:55 <clokep> Yes.
10:57:56 <aleth> flo-retina: Yes
10:58:02 <flo-retina> ok
10:58:17 <flo-retina> I'll propose a (hopefully) better help string wording in the bug then
11:06:53 --> nhnt11 has joined #instantbird
11:15:18 <nhnt11> flo-retina: I don't remember why the tab label is shown as "undefined", let me check quickly.
11:17:03 <nhnt11> aleth: Yes, in my next patch I intend to rewrite the initialization code to store contacts rather than the elements, and then create elements and show them when necessary.
11:17:17 <nhnt11> (I already have a WIP on that)
11:17:50 <aleth> nhnt11: Cool. Just have a JS object for each contact that contains an element property pointing at the corresponding DOM element if it exists (or something like that)
11:20:27 <nhnt11> Right. I have a contacts[] array already, I could have a linkedElt or something on each of them.
11:20:50 <aleth> I'd make it an items[] array and contacts are one of the possible item types...
11:21:15 <nhnt11> Ah for MUCs. Right. I'll rename it.
11:21:53 <nhnt11> I don't think the awesometab should do much differentiation between the types of items. That should be handled in build()
11:22:07 <nhnt11> Perhaps the name of the contact binding should be changed as well then.
11:22:09 <flo-retina> aleth: sounds like if nhnt11 needs an exercise for that, we could make him fix the pref issue of the nicklist ;).
11:22:25 <aleth> nhnt11: However you do it, I think it'll be helpful to keep the final goal (to the extent it is clear) in mind as you implement, to avoid having to refactor lots later.
11:22:32 <nhnt11> Right.
11:22:38 <flo-retina> aleth: I think we should really stop creating all DOM nodes in there, and just keep an array, and create the DOM nodes upon scrolling
11:22:48 <flo-retina> s/pref/perf/
11:23:13 <aleth> flo-retina: Yeah... but I wouldn't suggest it seriously as it will take up too much time
11:23:16 <nhnt11> flo-retina: The undefined isn't flashing anymore, just a blank title. I think it was a remnant of a WIP that I fixed.
11:23:27 <flo-retina> aleth: yeah :)
11:23:27 <aleth> We can always steal/adapt nhnt11's code for it later ;)
11:23:34 <flo-retina> aleth: only if he gets bored/stuck in reviews
11:23:54 * flo-retina goes away for lunch
11:28:41 <nhnt11> In an exported patch, does the branch name, parent node etc matter?
11:29:12 <nhnt11> i.e. Does it matter if it says Branch: aboutpages? :P
11:46:41 <instantbot> nhnt11@gmail.com requested review from florian@instantbird .org for attachment 2520 on bug 2002.
11:46:44 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2002 enh, --, ---, nhnt11, NEW, Add an /about command to open the about:* pages
11:55:17 <-- EionRobb has quit (Quit: Leaving.)
11:55:40 --> EionRobb has joined #instantbird
11:57:21 <-- EionRobb has quit (Ping timeout)
11:59:43 --> clokep_ has joined #instantbird
12:00:29 --> dionisos has joined #instantbird
12:02:04 <clokep_> nhnt11: No.
12:03:37 <instantbot> aleth@instantbird.org granted review for attachment 2519 on bug 2006.
12:03:40 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2006 enh, --, ---, clokep, ASSI, The /invite command should support taking more than one nick as parameter
12:03:44 <clokep_> flo-retina: I thought about checking if there weroe multiple channels but decided against it, I can certainly add it though.
12:06:04 <-- Optimizer has quit (Ping timeout)
12:08:09 <aleth> clokep_: Aren't unprefixed channel names possible in principle?
12:09:11 <clokep_> aleth: No!
12:09:18 <clokep_> How would you tell between a channel and a nick? :-S
12:09:38 <aleth> clokep_: I somehow remembered it was not possible to do just that :-/
12:09:52 <aleth> I'm glad I was mistaken ;)
12:11:08 <aleth> I wonder why I thought that :-S
12:13:47 <instantbot> aleth@instantbird.org denied review for attachment 2519 on bug 2006.
12:13:49 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2006 enh, --, ---, clokep, ASSI, The /invite command should support taking more than one nick as parameter
12:16:16 <aleth> Ah, maybe it was that the intersection of the list of channel prefixes with the list of possible (nonstandard) channel mode nick prefixes is not empty.
12:16:47 <clokep_> Yes, that's true.
12:22:17 <clokep_> You didn't have to make it sound like I wrote an awful patch. :P
12:22:58 <aleth> clokep_: Did I? :o That was not intentional, I did r+ it at first after all ;)
12:23:29 <aleth> I just meant that it's actually possible to do more parameter checking...
12:24:05 <clokep_> Yes, I know. :)
12:29:11 <-- qlum has quit (Ping timeout)
12:32:45 --> qlum has joined #instantbird
12:33:22 --> Kaishi has joined #instantbird
12:36:00 * qheaden_away is now known as qheaden
12:36:05 <qheaden> Hello everyone!
12:36:07 * qheaden clocks in.
12:38:07 <clokep_> Good morning.
12:39:32 * clokep_ needs to write on his blog about qheaden. :-/
12:40:07 * qheaden didn't realize clokep_ had a blog.
12:40:11 * aleth hopes the new yahoo prpl can land pref'd off once conversations are possible ;)
12:40:24 <qheaden> aleth: You will be forced to use it!
12:40:43 <-- clokep has quit (Ping timeout)
12:40:49 <aleth> qheaden: Heh, indeed. I don't use Yahoo atm.
12:40:57 <qheaden> :)
12:46:04 <clokep_> aleth: Yeah I've been trying to think of a way to do that. Have you got any ideas?
12:46:14 <clokep_> qheaden: I do... http://clokep.blogspot.com/
12:46:50 * nhnt11 finds blogging tedious :(
12:47:41 <qheaden> nhnt11: Same here, as I'm not a writer. :(
12:48:03 <nhnt11> qheaden: At least you remember to do the daily logs :(
12:48:09 * nhnt11 should really stop being lazy and write them.
12:48:21 <aleth> clokep_: Without looking at the code - maybe if there are 2 prpls of the same id (prpl-yahoo) check a pref for whether to use the JS one?
12:48:29 <qheaden> clokep_: So when we are able to pref the prpl off, will I finally be able to call it "Yahoo" instead of "Yahoo Test" in the manifest?
12:49:39 <clokep_> qheaden: Yes.
12:53:28 <qheaden> clokep_: BTW, I'm finding that buddy authorization bug hard to test. After removing and adding a buddy a few times, I couldn't reproduce it. 
12:53:41 <qheaden> So I'm just going to move on to conversations, and test things as I go.
12:54:16 <qheaden> And one more thing. After using WireShark, I see that buddy tags in Ib have no communication with the server.
12:55:03 <clokep_> qheaden: You mean from libpurple?
12:55:04 <aleth> clokep_: Maybe here http://lxr.instantbird.org/instantbird/source/chat/components/src/imCore.js#302
12:55:20 <qheaden> clokep_: Yes.
12:55:41 <clokep_> aleth: Seems reasonable, yes. :)
13:02:26 <instantbot> New Core - General bug 2016 filed by clokep@gmail.com.
13:02:29 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2016 enh, --, ---, nobody, NEW, Allow switching between a JS and libpurple prpl via a pref
13:03:33 * clokep_ wonders whether qheaden should do that or I should do that.
13:05:25 <flo-retina> or maybe I should?
13:05:49 <clokep_> I really meant more of that I think "we" should do it instead of qheade n. :)
13:05:53 <clokep_> I'd prefer if you did it. ;)
13:05:59 <flo-retina> heh
13:07:44 <qheaden> :)
13:08:17 <qheaden> clokep_: Am I CC'd on bug 2016?
13:08:22 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2016 enh, --, ---, nobody, NEW, Allow switching between a JS and libpurple prpl via a pref
13:08:48 <qheaden> Nevermind, I got the notification.
13:09:42 <qheaden> Soooo... I'm just going to get started on conversation stuff to keep the ball rolling.
13:11:12 <clokep_> qheaden: Yes, I didn't mean to look at that now. ;)
13:12:28 <qheaden> Okay. :)
13:15:42 <flo-retina> looks like bug 2002 is ready to go :)
13:15:45 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2002 enh, --, ---, nhnt11, NEW, Add an /about command to open the about:* pages
13:16:03 <nhnt11> :)
13:16:14 <qheaden> clokep_: Instead of using this._socket.sendBinaryData(packet.toArrayBuffer()), should I add a send() method to YahooPacket that takes a socket as an argument?
13:17:24 <clokep_> qheaden: What? :-S WHy would you need that?
13:18:35 <qheaden> clokep_: Yeah, I guess it would be useless.
13:20:55 <clokep_> qheaden: It might be useful to make a send method: send(packet) this._socket.sendBinaryData(packet.toArrayBuffer()) ;)
13:21:46 <qheaden> clokep_: I guess, but that would probably just be unnecessary function calling.
13:23:08 <clokep_> qheaden: But if it makes the code easier to read and such, it's useful. :)
13:23:17 <clokep_> (Or maybe a sendPacket method)
13:23:31 <qheaden> clokep_: So you are saying I should add that to YahooSession right?
13:23:44 <clokep_> qheaden: It's a suggestion, not a directive.
13:24:30 <qheaden> OK. I'll keep things the same right now, and change them later.
13:24:43 <clokep_> OK. :)
13:24:44 <qheaden> It could be a part of a code cleanup.
13:32:01 <clokep_> Sounds like a plan.
13:32:15 <clokep_> qheaden: So you're starting with private conversations, right?
13:32:24 <qheaden> clokep_: Ues.
13:32:28 <qheaden> clokep_: *Yes
13:40:10 <clokep_> Excellent. :)
13:42:13 <clokep_> qheaden: Looks like you're making pretty good progress on your list.
13:42:25 <clokep_> After you get private conversations working, I'd like us to look at Yahoo JAPAN support.
13:42:52 <qheaden> clokep_: Yeah. In my proposal, I was scheduled to start work on conversations year the end of July. :P
13:43:05 <qheaden> *near
13:43:14 <flo-retina> nobody cares about schedules in proposals ;)
13:43:55 <qheaden> :P
13:44:02 <flo-retina> we reading these schedules, we just check that the relative amount of time you expect to spend on different parts of the project seems realistic and to match our understanding of the project
13:44:25 <flo-retina> if it doesn't match, either we need to discuss things further to clear misunderstanding, or the student has no idea of what he's talking/applying about.
13:44:47 <flo-retina> *when reading
13:44:55 <qheaden> I hope I finish the project early for two reasons. First, college starts again in August, and second, I want extra time in the end to tie up any loose ends.
13:45:12 <flo-retina> yeah, and don't underestimate review times ;)
13:45:21 <flo-retina> + the amount of bugs people find when they start dogfooding :)
13:45:28 <qheaden> :)
13:45:43 * qheaden is scared of the time when people start using his prpl.
13:45:54 <aleth> Always nice to be a bit ahead though ;)
13:47:37 <clokep_> qheaden: Yes, you started a couple weeks early too! :P
13:47:41 <clokep_> But that's excellent. :)
13:47:51 * clokep_ would like to get this landed ASAP!
14:00:47 <-- qlum has quit (Ping timeout)
14:02:57 * nhnt11 thinks he might be a teeny bit behind on his schedule.
14:03:14 <nhnt11> Probably worth investing time into the UX now than having to make huge changes later thouhg.
14:04:03 <aleth> I wouldn't say that, getting the tabbrowser rewiring done is a big step.
14:04:10 --> qlum has joined #instantbird
14:04:33 <nhnt11> I was referring strictly to the schedule in my proposal :)
14:05:09 * aleth wonders if the proposal even included the need for adding support for generic tabs ;)
14:05:17 <nhnt11> I don't think so. :P
14:05:41 * nhnt11 is thankful to be accepted even though he overlooked the tabbrowser :P
14:12:46 <clokep_> nhnt11: We wouldn't have expected you to know that. :)
14:12:54 --> mconley has joined #instantbird
14:12:54 <clokep_> And you're making good progress, just keep at it.
14:14:18 <nhnt11> :
14:14:19 <nhnt11> :)
14:14:43 <flo-retina> nhnt11: and the /about stuff wasn't exactly part of the (planed) project
14:14:55 <flo-retina> just a nice low hanging fruit :)
14:15:28 <nhnt11> I'm not worrying or complaining or anything, just made an observation ;)
14:15:51 <qheaden> clokep_: I was able to send a chat message!
14:15:53 * flo-retina wonders where Atul is compared to his schedule
14:16:00 <aleth> qheaden: :)
14:16:03 <nhnt11> qheaden: Congrats :)
14:16:11 <qheaden> Using the chat window too. :)
14:16:14 <flo-retina> qheaden: was it received at the other end? :)
14:16:22 <qheaden> flo-retina: Yep. :)
14:16:25 <aleth> qheaden: Was it "Hello world!"? ;)
14:16:26 <flo-retina> cool :)
14:16:47 * qheaden thinks the Yahoo! servers are starting to like him.
14:17:19 <qheaden> Now to work on receiving.
14:18:12 <clokep_> :)
14:18:13 <clokep_> Congrats.
14:18:46 * clokep_ keeps adding to https://etherpad.mozilla.org/ELTNA6O44F for qheaden  :P
14:18:53 <qheaden> :P
14:19:19 * qheaden still has to try out nhnt11's AwesomeTab.
14:21:00 <-- Kaishi has quit (Quit: Kaishi)
14:22:17 * nhnt11 just experienced the "url gets stuck in status bar" bug again :-/
14:22:51 <nhnt11> qheaden: You should probably wait for the next patch ;)
14:27:09 <nhnt11> flo-retina, aleth: I'm trying to implement a queue system for adding contacts similar to the conversation queue in imWindows
14:27:48 <nhnt11> Every time a contact is added, it asynchronously calls a function that adds the contact, or adds it to the queue if there is one.
14:28:01 <nhnt11> (Is the idea)
14:28:09 <flo-retina> what are you trying to achieve with this?
14:28:11 <nhnt11> Does this seem like a reasonable approach?
14:28:21 <flo-retina> or did you mean like the message queue in conversation.xml?
14:28:48 <nhnt11> It achieves a way to manage the displayed contacts asynchronously as well as (somewhat) efficiently.
14:28:54 <nhnt11> I haven't seen that.
14:29:06 <flo-retina> I still don't understand that goal
14:29:44 <flo-retina> why does it need to be asynchronous? Why wouldn't be be efficient enough to display all the 6 (or maybe up to 20) contacts at once?
14:30:06 <flo-retina> or are you talking about the back-end that will need to evaluate how important a contact is?
14:30:15 <nhnt11> No, just a second
14:30:39 <nhnt11> I've switched to using an array of contacts (as opposed to DOM elements). initBuddyList will now populate this array.
14:30:51 <qheaden> clokep_: It looks like the YMSG web client sends its messages surrounded with <font> tags. Is there any existing code that handles that?
14:31:02 <nhnt11> I need a way to simultaneously display a few of these contacts, while the list is populating
14:31:51 <aleth> nhnt11: Maybe you need to separate populating the list from the awesomepanel instance?
14:31:52 <nhnt11> i.e. I don't want to add the first 10 contacts /after/ initializing the whole contacts array.
14:32:19 <nhnt11> aleth: Do you think they could be maintained/cached in tabbrowser? I believe I was asking about something similar.
14:32:47 <aleth> Not there, but it seems a good idea not to recreate all the data everytime a newtab is opened
14:33:06 <nhnt11> Also, I need to consider the situation when a new contact is added that needs to be inserted at the top of the list..
14:33:17 <clokep_> qheaden: That does what?
14:33:20 <nhnt11> aleth: Right, makes more sense to store it in the contacts service.
14:33:35 <qheaden> clokep_: That handles <font> formatted messages.
14:33:56 <clokep_> qheaden: I still don't understand, incoming or outgoing messages?
14:34:02 <qheaden> clokep_: Sorry. Incoming.
14:34:02 <aleth> nhnt11: Idk, maybe the awesometab needs its own service ;) 
14:34:05 <clokep_> Are you trying to create a message with <font> tags or read them?
14:34:09 <flo-retina> interesting hack: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#3421
14:34:15 <qheaden> clokep_: Read them.
14:34:19 <flo-retina> code that executes only if a lazy getter has already been executed :)
14:35:15 <aleth> nhnt11: Maybe not a service, but just some JS that gets initialized when IB starts.
14:36:01 <clokep_> qheaden: One second, let me think.
14:36:06 <nhnt11> aleth: I'm confused. Where would such JS go?
14:36:25 <nhnt11> It needs to be available from all conversation windows.
14:36:44 <nhnt11> (And possibly in the buddy list too if we decide to use the "cache" there in the future)
14:37:12 <aleth> nhnt11: Ask flo, but I'd say in its own JS module, included where needed.
14:37:18 <aleth> JS modules have their own scope.
14:37:38 <qheaden> Does Ib even allow formatted messages, with different fonts and the like?
14:38:20 <nhnt11> qheaden: It appears so.
14:38:20 <clokep_> qheaden: Incoming, of course.
14:38:29 <clokep_> qheaden: Outgoing, we don't currently.
14:38:35 <qheaden> Okay.
14:38:41 <nhnt11> aleth: Cool. I'll take a look
14:38:42 <aleth> nhnt11: Maybe a JS module is overkill, idk. But you will want to keep up to date the data on contacts and MUCs and so on, and the data needed for sorting. That's the part that seems to me needs to be async
14:38:47 <clokep_> qheaden: So, I don't think you need to do anything special for this.
14:39:02 <clokep_> The conversation should handle that, but it only allows certain tags to go through, IIRC.
14:39:09 <aleth> nhnt11: Ask flo before you start implementing, I'm not certain on the best place to put this
14:39:12 <qheaden> clokep_: Just strip the tags, and read the message?
14:39:26 <nhnt11> I think it's something I should look into asap.
14:39:27 <nhnt11> flo-retina: ping
14:39:35 <flo-retina> nhnt11: pong
14:40:17 <nhnt11> flo-retina: aleth and I were discussing having a service or module that could be used to store and retrieve an updated sorted list of contacts.
14:40:42 <flo-retina> s/contacts/possible conversations/ ;)
14:40:47 <aleth> Well, ultimately not just contacts
14:40:55 <nhnt11> Right right.
14:41:09 <clokep_> qheaden: No, you don't have to strip the tags. :-S
14:41:11 <nhnt11> flo-retina: So.. do you have an opinion on where such code can go?
14:41:16 <aleth> And the data needed for sorting etc
14:41:17 <clokep_> qheaden: Just feed it through.
14:41:18 <nhnt11> i.e. A service, or a module, etc.
14:41:43 <clokep_> qheaden: Are you seeing it show up as text or something?
14:41:48 <clokep_> What's the issue you actually have? :-S
14:41:57 <nhnt11> Whatever this is is probably going to evolve into the "ranking system" in my proposal, I think.
14:42:04 <aleth> Right.
14:42:15 <qheaden> clokep_: To be honest, I was just looking at the incoming message from WireShark.
14:42:24 <qheaden> I wasn't aware the conversation will handle tags by itself.
14:42:53 <aleth> qheaden: Whether tags like that are stripped or not depends on a setting in Preferences
14:43:11 <qheaden> ok
14:43:22 <clokep_> qheaden: http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#322 might matter to you.
14:43:26 * nhnt11 has that pref set to "only basic formattings"
14:43:51 <clokep_> qheaden: But I don't think so, since you can just pass it through. :)
14:44:00 <qheaden> Ahh okay. Great.
14:44:09 <clokep_> (Although shouldn't the prpl handle that stuff? :-S)
14:44:19 <clokep_> Oh! That's outgoing messages.
14:44:21 <clokep_> Ignore me. :)
14:45:20 * clokep_ can't find where we do it right now...
14:45:38 <qheaden> clokep_: Don't worry about it now.
14:46:18 <clokep_> But, yeah. Anyway...if it's a sane protocol and sends HTML then it's not really up to the prpl to care about it. :)
14:46:31 <clokep_> If it's something like IRC and sends crazy command codes...welll...then you gotta be concerned. :)
14:47:04 <flo-retina> nhnt11: instantbird/components/ if you go for a service. instantbird/modules/ if you go for a module
14:47:07 <aleth> mirc color codes... sssh ;)
14:47:24 <nhnt11> flo-retina: Do you have a preference over service/module?
14:47:30 * nhnt11 thinks a module might be the better option
14:48:18 <clokep_> What is this service/module for?
14:48:20 <aleth> It depends on your API for it
14:48:22 * clokep_ must have missed some context.
14:48:50 <flo-retina> clokep_: storing statistical data about previous conversations, so that it doesn't take much computation to get the list of stuff to show in the awesometab when opening it
14:48:55 <aleth> You probably have to think a bit about how it will be organized/interact with the rest of the code, and then decide.
14:49:22 <flo-retina> nhnt11: it's not very important and would likely be easy to switch between the two later.
14:49:25 * clokep_ has a feeling that should be a module.
14:49:29 <clokep_> Oops, I mean service. :)
14:49:57 <flo-retina> nhnt11: I would likely go with a component started at startup, that does its stuff in the background and listens for notifications about new conversations, new contacts, etc...
14:50:55 <aleth> That's what I suggested too
14:54:09 <nhnt11> Can't both services and modules do this?
14:54:27 <aleth> Sure, but the implementation would be slightly different
14:54:30 <flo-retina> nhnt11: a module needs to be imported by something at least once to get started
14:54:42 <flo-retina> nhnt11: so if you start it from ibCore.jsm, that would work
14:54:48 <nhnt11> Yeah
14:55:00 <flo-retina> as I said "it's not very important and would likely be easy to switch between the two later." ;)
14:55:04 <nhnt11> Cool.
14:55:09 <nhnt11> I'll start it off as a module.
14:55:34 <flo-retina> a reason to prefer a component is that it would force you to define a clear interface (Atul's new hobby ;)) for the API
14:55:38 <nhnt11> I'll start on that as soon as I clean up the awesometab.xml code.
14:55:53 <flo-retina> but you can start as a module and move it later to a component to document the API
14:57:06 <nhnt11> flo-retina: If you think it would be advantageous as a component, I'd rather do it as a component from the beginning.
14:57:14 * nhnt11 will do a bit more research on this.
14:58:51 <aleth> The AwesomeService (TM) :P
14:59:08 <nhnt11> :P
15:02:45 <qheaden> aleth: (SM) ?
15:02:47 <qheaden> :)
15:03:42 <aleth> qheaden: I guess :D
15:04:21 <qheaden> Ha ha. I was able to receive a chat message, but the font is HUGE.
15:04:41 <qheaden> The Yahoo web client sends Arial 14 messages.
15:05:48 <aleth> At least they're not Comic Sans.
15:06:02 <qheaden> :P
15:12:16 <clokep_> qheaden: Does libpurple handle that speically?
15:12:57 * qheaden goes to check the libpurple source.
15:21:53 <qheaden> clokep_: It does handle the tags in a few places. One of them: http://lxr.instantbird.org/instantbird/source/purple/libpurple/protocols/yahoo/util.c#516
15:22:09 <clokep_> flo-retina: What would "host closed the connection" mean? We closed it or the server?
15:22:25 <flo-retina> the server
15:23:08 <aleth> clokep_: Do you think this would fix bug 1942? http://pastebin.instantbird.com/232247
15:23:15 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1942 nor, --, ---, nobody, UNCO, Irc Networks disconnect then imminently reconnect again.
15:23:25 <clokep_> aleth:Talking to someone in #thunderbird
15:23:54 <clokep_> qheaden: I see...I'd say don't worr yabout that yet.
15:24:29 <qheaden> clokep_: Okay.
15:30:55 <aleth> clokep_: Take a look when you get a chance. Of course I have no idea if it would fix qlum's problems, but it seems to me we are currently doing the wrong thing there.
15:32:07 <-- aleth has quit (Quit: Ciao)
15:35:24 <clokep_> aleth: One second.
15:36:53 <clokep_> aleth: That change makes no sense.
15:37:01 <clokep_> We already call resetPingTimeout on every received message.
15:37:22 <clokep_> And cancelDisconnectTimer is specifically meant for a ping response: http://lxr.instantbird.org/instantbird/source/chat/modules/socket.jsm#57
16:01:38 --> Nirgali has joined #instantbird
16:04:13 <-- Nirgali has quit (Ping timeout)
16:22:52 * nhnt11 was distracted by Wimbledon
16:27:47 * qheaden is chatting with his mom using the new prpl.
16:28:23 <nhnt11> Cool!
16:31:38 --> Mook_as has joined #instantbird
16:39:07 <flo-retina> qheaden: is she scared that you are using unstable software? ;)
16:40:17 <flo-retina> (I'm asking because you said you were 'scared of the time when people start using [your] prpl') ;)
16:40:24 <qheaden> flo-retina: Nah. She's used to being a alpha/beta tester for my projects. :P
16:41:01 <qheaden> flo-retina: I'm mainly scared when people like you start using it. You guys have a keen eye for bugs. :P
16:41:15 <flo-retina> qheaden: don't be scared, I don't have any yahoo contact ;)
16:41:57 <qheaden> ha ha
16:45:55 <Mook_as> oh, wow, they do have a special case to remove all font sizes from yahoo...
16:48:39 <qheaden> Mook_as: Where at?
16:49:05 <qheaden> Looks like I'm going to have to do the same thing. Messages from the Yahoo web client are gigantic in Ib.
16:49:36 <Mook_as> qheaden: http://lxr.instantbird.org/instantbird/source/purple/libpurple/protocols/yahoo/util.c#442
16:50:38 <qheaden> Mook_as: Ah! I missed that detail.
16:51:24 <-- mconley has quit (Connection reset by peer)
16:51:41 --> mconley has joined #instantbird
16:57:58 --> Nirgali has joined #instantbird
16:59:00 <-- gerard-majax_ has quit (Ping timeout)
16:59:11 <qheaden> Does Ib/Mozilla provide any helper methods to easily tweak an XML tag?
16:59:26 <qheaden> Stripping tags, attributes, etc?
17:04:10 <qheaden> I'll be back in a bit
17:04:14 * qheaden is now known as qheaden_away
17:06:50 <clokep_> qheaden_away: As a string or as a DOM?
17:06:53 <clokep_> Mook_as: nice find. :)
17:09:46 * mconley is now known as mconley|away
17:19:21 <-- qlum has quit (Ping timeout)
17:21:13 --> qlum has joined #instantbird
17:38:38 * nhnt11 is not liking dynamically removing/adding DOM elements instead of using CSS to filter contacts.
17:38:41 <nhnt11> (It's slower)
17:39:10 <nhnt11> At least for the blist-tab, I think CSS is the better way.
17:42:26 --> gerard-majax_ has joined #instantbird
17:50:14 <clokep_> :(
17:50:45 <flo-retina> nhnt11: "it's slower" can you elaborate on that?
18:04:00 <nhnt11> flo-retina: Adding a keyup listener which reloads the list makes typing lag a teeny bit for me
18:04:20 <clokep_> nhnt11: You probably need to do it smartly and not do it every single time there's a keyup.
18:04:25 <nhnt11> Adding a listener to the "command" event isn't instant :/
18:04:49 <nhnt11> clokep_: I tried using the "command" event on a "search" textbox but it just doesn't feel the same.
18:05:06 <nhnt11> Doesn't have that snappy feel to it and I think the snappiness is important.
18:05:15 <clokep_> That wasn't what I was suggesting.
18:05:46 <nhnt11> clokep_: The command event fires every time the user stops typing.
18:06:01 <nhnt11> Rather, it waits for a slight pause in typing before firing
18:06:06 <clokep_> OK.
18:06:08 <nhnt11> Which is what you were suggesting, I think.
18:06:19 <clokep_> Not really, I meant more of possibly skipping
18:06:27 <clokep_> Some keyup events or something.
18:06:31 <clokep_> But I dk how that works well
18:07:07 <nhnt11> The lag will probably be nonexistent on a more recent CPU than mine.
18:08:20 <nhnt11> It's nearly unnoticeable for me too.
18:09:28 <flo-retina> nhnt11: are you getting rid of the whole list and fully redisplaying each time?
18:10:17 <nhnt11> flo-retina: The "whole list" is 10 elements.
18:10:18 <nhnt11> But yes.
18:10:35 <nhnt11> Though I don't intend to do that in a final version.
18:11:13 <flo-retina> can't you compare the existing items and the new items, and be smarter about which DOM manipulations you do?
18:12:02 <nhnt11> I can and will, but it's still likely going to involve removing/adding 10 elements.
18:12:11 <-- mconley|away has quit (Connection reset by peer)
18:12:23 --> Optimizer has joined #instantbird
18:12:29 --> mconley|away has joined #instantbird
18:12:56 <flo-retina> that shouldn't be slow.
18:13:14 <-- flo-retina has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
18:48:14 <-- Nirgali has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
18:48:15 --> Nirgali has joined #instantbird
18:53:15 --> mpmc has joined #instantbird
19:11:21 --> Mic has joined #instantbird
19:11:21 * ChanServ sets mode +h Mic 
19:12:05 <Mic> Hi
19:12:29 <clokep_> Hello.
19:12:44 <nhnt11> Hi
19:20:01 * nhnt11 doesn't like his code
19:33:55 --> unghost has joined #instantbird
19:41:38 <clokep_> nhnt11: r? :P
19:41:44 <clokep_> Is the about patch landing tonight?
19:41:57 <nhnt11> I think so. Flo said it looked good to go right?
19:42:20 <nhnt11> And I think not, I'd r- this myself without a second glance.
19:42:31 <nhnt11> Rewriting a lot of this code right now.
19:43:51 <Mic> nhnt11: which code are we talking about?
19:44:03 <Mic> The about:pages are going to land tonight, aren't they?
19:44:04 <-- gerard-majax_ has quit (Ping timeout)
19:44:13 <nhnt11> Mic: The blist-tab code.
19:44:17 <nhnt11> Yes, I think so.
19:44:44 <Mic> That's not reviewed yet, is it?
19:45:12 <nhnt11> No, but flo approved on IRC.
19:45:44 * nhnt11 is slowly memorizing the XULNS.
19:46:33 <clokep_> XUL!!!
19:47:06 <nhnt11> Scratch that, /me has memorized the XULNS.
19:52:08 <-- mconley|away has quit (Connection reset by peer)
19:52:20 --> mconley|away has joined #instantbird
19:55:52 * qheaden_away is now known as qheaden
19:57:34 <nhnt11> | delete obj[key] | completely removes that key/value pair from obj right?
19:57:51 <nhnt11> Nvm, looked it up.
19:59:29 <clokep_> nhnt11: Should, yes.
20:00:06 <qheaden> clokep_: What do you think of the changes so far? http://pastebin.instantbird.com/232369
20:02:54 * nhnt11 completely rewrote the filtering stuff keeping the advice about DOM elements in mind.
20:03:01 <Mic> :)
20:03:24 <clokep_> qheaden: Needs comments.
20:03:38 <Mic> nhnt11: let me know when you think that I should have a look!
20:04:22 <nhnt11> Mic: Sure thing, I just need to setup the event listeners and observers properly and test it a bit and I'll let you know :)
20:04:24 <clokep_> qheaden: Overall it looks OK. :)
20:05:00 <qheaden> clokep_: OK, great.
20:05:56 <qheaden> clokep_: How do you suggest I handle the <font> stuff? Just do some operations with substring to remove it?
20:06:23 <Mic> qheaden: does Yahoo send markup by default?
20:07:01 <qheaden> Mic: Not really sure. The web client does. I have to try out the native desktop client.
20:07:03 <Mic> Isn't it filtered out anyways by our cleanup code in imContentSink.jsm (iirc)?
20:07:11 <clokep_> qheaden: I'd need to see an example of what we receive and what you want it to look like.
20:07:20 <clokep_> Mic: We had that conversation earlier today, it's a different thing.
20:07:20 <qheaden> Let me get a screenshot going.
20:07:36 <Mic> qheaden, clokep_: ignore me then :)
20:09:57 <clokep_> ;)
20:10:12 <clokep_> qheaden: Do you mean the same operations that libpurple does?
20:15:55 * nhnt11 runs his code and prepares for errors.
20:17:20 <qheaden> clokep_: Here's what's happening: http://imgur.com/pz3VbVG
20:19:45 <clokep_> qheaden: OK.
20:21:44 * nhnt11 wishes there was a faster way to fix small errors than to re-make tier_app.
20:21:52 <nhnt11> fix and test*
20:23:55 <-- mpmc has quit (Connection reset by peer)
20:29:02 <Mic> qheaden: the black look of the messages on the screenshot is because of missing incoming/outgoing flags on the messages most likely.
20:29:10 <Mic> Just in case you didn't know that yet.
20:29:32 <qheaden> Mic: Ahh okay. I was wondering that in the back of my head.
20:30:54 <nhnt11> XBL!!!
20:31:34 <nhnt11> I tried to access a property after removing the element from the DOM
20:31:36 <nhnt11> Sigh
20:32:32 --> EionRobb has joined #instantbird
20:38:43 <qheaden> Mic: Would setting the outgoing flag to false indicate an incoming message?
20:39:17 <clokep_> qheaden: No.
20:39:18 <qheaden> Nevermind, I see on LXR you set incoming to true.
20:39:24 <Mic> If it is an incoming message, you should set the incoming flag to true
20:39:24 <clokep_> qheaden: Setting the incoming flag to true would.
20:39:33 <clokep_> qheaden: You should read the interface for messages.
20:39:39 <Mic> http://lxr.instantbird.org/instantbird/source/chat/components/public/prplIMessage.idl#22
20:40:10 <qheaden> Mic, clokep_: Thanks.
20:41:16 <nhnt11> Phew, it's mostly all working.
20:43:06 <nhnt11> There's still a small lag when accounts come online and all the associated contacts change status, but this doesn't seem to be blisttab-related.
20:43:15 <nhnt11> (It lags even if there's no blist-tab opened)
20:44:30 <nhnt11> Also there's a slight delay as it loads the contact list, but this should be solved once the service/module is written.
20:46:41 <nhnt11> Does Array.filter not guarantee preservation of order?
20:47:17 <Mic> nhnt11: I'd expect it to preserve the order... I don't know for sure though.
20:48:48 <nhnt11> It looks like it does according to my googling.
20:48:51 <nhnt11> Hmm
20:49:24 <Mic> What problem are you seeing?
20:49:59 <nhnt11> Um
20:50:36 <nhnt11> I'm having a problem while backspacing in the awesomebar, where sorting isn't quite right.
20:50:55 <nhnt11> I mean, elements are getting re-inserted wrong.
20:51:01 <nhnt11> I think I just found out why though.
20:51:24 --> flo-retina has joined #instantbird
20:51:25 * ChanServ sets mode +qo flo-retina flo-retina 
20:52:54 <-- clokep_ has quit (Quit: http://www.mibbit.com ajax IRC Client)
20:53:01 <nhnt11> Working now :)
20:54:39 <nhnt11> I have a couple more small issues I want to work out, and then I'll post my code :)
20:59:44 * qheaden is now known as qheaden_dinner
21:03:44 * Mic is curious how it looks and feels now :)
21:05:50 <nhnt11> Nearly the same, just that it displays only 10 contacts at a time :)
21:06:14 <nhnt11> Also I was able to get rid of that alternating backgrounds hack ;)
21:07:11 <nhnt11> Is there a notification for an account coming online?
21:08:10 <Mic> Yes
21:08:41 <Mic> https://wiki.instantbird.org/Instantbird:Notifications:trunk
21:08:58 <Mic> We should make sure that this is uptodate :S
21:10:11 <nhnt11> Let me explain where I'm going with this... Assuming that tons of contacts don't change status at once, it's trivial to update the list when a contact changes a property and sends an observer notification. The problem is when an account goes online/offline, all of those contacts send a notification which causes the filtering to be done hundreds of times. If we instead add observers to the sign on/off notification, we can avoid this.
21:10:17 <nhnt11> (Sorry for the long message)
21:11:45 <nhnt11> If I'm right in assuming that "Status unknown" implies the account is offline, we can simply ignore status changes from/to "unknown" since it will be handled by the "account-signing-on" notification.
21:14:32 <Mic> I'm not sure what's happening when you say that it causes the filtering to happen hundreds of times.
21:14:56 <nhnt11> Let me show you some code for context
21:15:07 <Mic> Good idea ;)
21:15:29 <nhnt11> Here's my filter function: http://pastebin.instantbird.com/232391
21:16:16 <nhnt11> I can simply call this from observe() if small numbers of contacts are changing at a time.
21:16:51 <nhnt11> But if loads of contacts change at once, then observe will be called that many times, and so filter also.
21:16:54 <nhnt11> Which is... bad.
21:18:35 <nhnt11> Btw, this.contactElts is a list of currently displayed contact elements.
21:19:14 <nhnt11> (I'll generalize "contact" to "anything that can open a conversation" after I fix up this observe stuff)
21:21:42 <Mic> Let me think for a moment...
21:22:57 <nhnt11> If you'd like to see more code, let me know
21:23:07 <nhnt11> Let me just post it anyway, hold on.
21:24:45 <flo-retina> nhnt11: have you read the log today?
21:25:01 <Mook_as> you could also delay the filtering by a small amount from the first notification (i.e. batch them)?
21:25:03 <flo-retina> especially http://log.bezut.info/instantbird/130626#m117
21:25:27 * nhnt11 saw that in the wee hours of the morning and forgot about it
21:26:43 <flo-retina> nhnt11: Mook_as just proposed the same thing anyway ;)
21:27:19 <Mook_as> flo-retina: out of my head. err, about 11 hours ago? :p
21:27:28 <nhnt11> flo-retina: I don't know what executeSoon does, or how to use it :S
21:27:50 <Mic> nhnt11: don't use this "self"-pattern by the way. Filter takes an parameter that is used as this in the callback. (Before I forget to mention that).
21:28:17 <nhnt11> Mic: I saw that just a few minutes ago and made a mental note to change it ;)
21:29:11 * nhnt11 found a discussion on executeSoon from an old #instantbird log
21:29:39 <Mook_as> or you can embrace the newness. http://pastebin.instantbird.com/232404
21:29:53 <Mook_as> (I only changed line 7)
21:30:07 <Mic> Does that work for us already?
21:30:24 <Mook_as> umm... I can't remember which version you're on, sorry
21:30:29 <Mic> 21
21:30:38 <Mic> Afaik it's coming with 22 or 23
21:30:50 <nhnt11> flo-retina: Okay, it seems executeSoon is just a mainThread.dispatch(). How would this help?
21:31:03 <flo-retina> nhnt11: how would this _not_ help?
21:31:03 <nhnt11> How does it prevent the function from being called a load of times?
21:31:29 <Mic> nhnt11: could you pastebin the rest of it?
21:31:46 <nhnt11> Mic: Oops, forgot to post the link.
21:31:54 <nhnt11> http://pastebin.instantbird.com/232393
21:32:15 <Mic> Thanks
21:32:17 <nhnt11> (finishImport isn't ready at all, though I think it just needs a filter() at the end)
21:32:46 <flo-retina> nhnt11: http://pastebin.instantbird.com/232405
21:33:23 <nhnt11> Ah.
21:34:24 <-- mconley|away has quit (Connection reset by peer)
21:34:39 --> mconley|away has joined #instantbird
21:36:07 <nhnt11> I discarded a similar approach because: Consider a situation when you have an account going offline. filter() gets called once for all the 100 or so contacts in that account. Now, while filter() is executing, another completely unrelated contact goes offline/online. filter() won't be called, though it needs to be.
21:37:11 <flo-retina> you are assuming that filter is non blocking.
21:37:14 <flo-retina> that's not true.
21:37:25 <flo-retina> the JS engine is mono-threaded.
21:37:30 <flo-retina> While your code executes, nothing else happens.
21:38:30 * nhnt11 needs to think a bit.
21:38:57 <Mic> About the "elements to remove" code: I think I'd rather set "eltsToRemove = this.contactElts" and then splice the up to ten first elements from filteredContacts from it.
21:40:08 <nhnt11> Is that more advantageous than filtering?
21:40:21 <nhnt11> Ah, indexOf is likely bad
21:40:30 <nhnt11> Okay, thanks.
21:40:36 <Mic> Wait ... is contactElts a kind of cache or the actually displayed items only (i.e. only 10 items at best)?
21:40:52 <nhnt11> The actually displayed items only
21:41:03 <nhnt11> It's an array version of blist.childNodes.
21:41:06 <Mic> OK, nevermind.
21:41:27 <nhnt11> I should probably make it a property that returns blist.childNodes.
21:41:29 <Mic> I thought you'd be looking up lots and lots of positions there.
21:41:37 <nhnt11> No no :
21:41:38 <nhnt11> :)
21:42:26 * mconley|away is now known as mconley
21:43:06 <Mic> Use let filterStr = this.awesomebar.value.toLowerCase(); and compare against that from your callback by the way.
21:43:21 <nhnt11> Mic: I thought of that too! :)
21:43:31 <nhnt11> It would save getting the string in every iteration
21:44:07 * nhnt11 is trying to decipher the series of events in that situation he was thinking about
21:46:35 <flo-retina> if you still have performance problems after cleaning up the obviously slow code, maybe we will find motivation again to make the profiler work :)
21:47:53 <nhnt11> flo-retina: I'm not having any noticeable performance problems right now except for the account went offline thing.
21:48:03 <nhnt11> flo-retina: I'm still having trouble with the series of events here.
21:48:03 <nhnt11> :(
21:48:18 * nhnt11 shakes his head in an effort to clear it.
21:48:32 <flo-retina> have you said typing something in the filter box wasn't snappy?
21:48:44 <nhnt11> No, it's fine with the new code.
21:48:48 <nhnt11> (I rewrote most of it)
21:49:06 * Mic has a slow computer ;)
21:49:24 <Mic> I guess I'll find all the snappiness problems ;)
21:49:46 <nhnt11> Hey, I don't exactly have state of the art hardware either ;)
21:50:28 <flo-retina> I have an old macbook too
21:50:45 <flo-retina> but I need to find motivation to update the OS on it, so that it can run current nightlies :-/
21:51:06 <nhnt11> flo-retina: So you say that using executeSoon and checking if it's already running will solve my problmes?
21:51:35 * nhnt11 is thinking of trusting flo-retina on this and thinking more about it in the morning when he's more awake.
21:53:54 <Mic> nhnt11: do you know about "Map" and "Set" by the way?
21:54:27 <nhnt11> Mic: If you mean Array.map, yes. Otherwise, no. I don't know about Set.
21:54:39 <Mic> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
21:55:00 <nhnt11> Oooh okay.
21:55:07 * nhnt11 was thinking of other things.
21:55:08 <Mic> Ignore the warning for now, we're using it elsewhere already ;)
21:55:45 <nhnt11> Is there any advantage to using a Map rather than just using an Object?
21:56:39 <nhnt11> Oh there's a section on that in that page.
21:59:30 <Mic> Additionally you can't get problems when funny names make it into your object.
22:00:20 <nhnt11> Mic: I don't see an obvious use case in my code.
22:00:37 <Mic> Aren't you using an object as Map somewhere?
22:00:51 <nhnt11> contactsById and contactEltsById
22:01:04 <nhnt11> I could use maps instead of those but I don't see any obvious advantage.
22:04:16 <flo-retina> are the ids always numbers?
22:04:32 <nhnt11> flo-retina: Are you saying that while filter() is executing, new observer notifications will wait?
22:04:34 <nhnt11> Yes.
22:04:51 <flo-retina> nhnt11: now observer notifications won't even exist.
22:05:23 <flo-retina> incoming data will wait on the network thread and won't be processed until your function returns
22:05:43 <flo-retina> s/now/new/
22:05:45 <Mic> flo-retina: yes, it's the id of the imIContact.
22:06:06 <flo-retina> Mic: so map doesn't seem to have any advantage in this case; it's just a heavier syntax
22:06:40 <nhnt11> flo-retina: Account goes offline, hundreds of contacts go offline. Observer notification is received for one of those hundreds, filter() is called. I'm confused past this point. What happens to the notifications from the other hundreds of contacts, if filter blocks?
22:07:03 <flo-retina> no, you are confused at the step just before this point :-P
22:07:10 <nhnt11> :S
22:08:06 <flo-retina> Account goes offline, hundreds of contacts go offline. Observer notification is received for one of those hundreds, executeSoon is called with a filter function as parameter and a variable is set to true to remember that a filter call is pending. Other notifications are dispatched and ignored. executeSoon executes the filter function.
22:08:09 <Mic> Shall I explain?
22:08:17 <Mic> Ah...
22:08:52 <nhnt11> flo-retina: How is it guaranteed that executeSoon will execute only after all those hundreds of notifications are fired?
22:08:58 <nhnt11> (and ignored)
22:09:16 <nhnt11> Is it because the priority is normal, the system waits for idle time before executing?
22:09:21 <flo-retina> nhnt11: unless the prpl code itself also calls executeSoon in the middle of dispatching the notifications, yes.
22:10:12 <nhnt11> I see.
22:10:19 <flo-retina> ah, I missed the "how" word of your question.
22:11:25 <flo-retina> so no, it's not technically guaranteed but I would r- a patch doing something silly with these notifications, so you shouldn't have to worry
22:12:11 <nhnt11> "It's not technically guaranteed" <- This annoys me -_-'
22:12:37 <nhnt11> But okay.
22:13:48 <nhnt11> brb
22:14:08 <flo-retina> nhnt11: think about the stuff that's executed as a queue of events (an event can come either from the user, the OS, the network). When there's an event, some code is executed. No other code runs until that code has returned. So assume an account gets disconnected. The account code will loop over the list of contacts of the account, and set their status to Unknown. Notifications will be dispatched synchronously. During all that time, no
22:14:08 <flo-retina> event is processed
22:14:56 <flo-retina> the code in executeSoon pushes a function to be executed as if it was the next event (it just adds the function to the queue of events needing to be processed). So it will be processed as soon as all ongoing stuff is finished.
22:16:17 <nhnt11> flo-retina: Got it.
22:16:18 <nhnt11> Thanks.
22:16:32 <nhnt11> Cool.
22:16:34 <flo-retina> you are welcome
22:16:50 <flo-retina> I just hope my explanations are clear; and not confusing you even more :)
22:17:03 <-- qlum has quit (Ping timeout)
22:17:05 <nhnt11> Nope, it's clear now.
22:19:47 <nhnt11> I should probably do executeSoon in my keyup listener as well, then.
22:20:18 <flo-retina> maybe (that's less obvious in that case)
22:20:40 --> qlum has joined #instantbird
22:20:42 <nhnt11> flo-retina: It /may/ prevent lag for super fast typists on a slow computer.
22:20:48 <Mic> http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#805
22:21:16 <flo-retina> nhnt11: it wouldn't really
22:21:52 <flo-retina> hmm, well, if the word appears all at once, then yes, it would save redisplaying the list of each charachter
22:22:15 <nhnt11> Yeah.
22:22:27 <nhnt11> I think the link Mic just posted is for a similar purpose.
22:22:47 <Mic> flo-retina: wasn't that the reason why we did what we did in the link that I just pasted?
22:25:44 <-- unghost has quit (Quit: Ухожу я от вас (xchat 2.4.5 или старше))
22:26:06 <flo-retina> Mic: yes
22:26:50 <nhnt11> Mic, flo-retina: So I think this should take care of both the observers and keyup? http://pastebin.instantbird.com/232439
22:27:30 <flo-retina> Mic: was I was poorly trying to say is that it won't help keep things smooth if the machine can't keep up with what you are doing. It will only help the machine catch up if it was already behind for some reason (swapping off to disk is a likely reason)
22:30:16 <flo-retina> *what I was
22:30:55 <Mic> I didn't notice ;)
22:30:57 <-- Nirgali has quit (Ping timeout)
22:31:47 <Mic> Maybe because both it's late already and the german word for "what" is ... "was" ;)
22:33:28 <nhnt11> flo-retina: So... it doesn't work
22:33:44 <nhnt11> Taking an account online resulted in a ton of filters being called
22:33:58 <flo-retina> Mic: yeah, it's late
22:34:10 <flo-retina> I need to get up early tomorrow; going to Paris again :-/
22:34:31 <nhnt11> Interesting, taking an account /off/line called it only once.
22:34:33 <Mic> "filter" will be called. DelayedFilter shouldn't.
22:34:43 <nhnt11> Sorry I meant delayedFilter.
22:34:47 <flo-retina> nhnt11: you discussed the "offline" case
22:34:57 <flo-retina> nhnt11: online is different, because it's possible the server sends us chunked data.
22:35:07 <nhnt11> Taking the same account online again called it less than 10 times
22:35:11 <flo-retina> nhnt11: for the offline case, everything happens locally, so all notifications are sent at once ;)
22:35:41 <nhnt11> Heh
22:35:44 <nhnt11> Well it's still fast
22:35:47 <nhnt11> Much better than before
22:35:47 <nhnt11> :)
22:36:29 <flo-retina> yes, even if it's called more than once, it shouldn't be cause performance issues, as all the data received from the network will be processed before the next call
22:36:35 <nhnt11> Mic, flo-retina: So is the new code more similar to what you were expecting with handling the DOM elements?
22:36:46 <flo-retina> the faster your machine and the slower your internet connection, the more calls the function will receive.
22:36:51 * qheaden_dinner is now known as qheaden
22:36:51 <nhnt11> Right.
22:37:19 <flo-retina> nhnt11: I haven't looked at the code at all yet. But from the discussions I saw today, the answer is very likely yes
22:37:37 <Mic> Let me decide that tomorrow, OK?
22:37:41 <nhnt11> Sure.
22:37:46 <Mic> I've put it on my todo list already.
22:38:00 <Mic> (i.e. feedback on the buddy list tab in general)
22:38:02 <nhnt11> flo-retina: Will bug 2002 land tonight?
22:38:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2002 enh, --, ---, nhnt11, NEW, Add an /about command to open the about:* pages
22:38:12 <nhnt11> Mic: Sounds good. I need to sleep too anyways.
22:38:25 * Mic too.
22:38:28 <flo-retina> nhnt11: I'll look at it within the next 10 minutes or so, and then go to bed
22:38:32 <Mic> Good night then!
22:38:35 <nhnt11> Sure.
22:38:39 <nhnt11> Good night!
22:38:53 <flo-retina> errr, and then book my train ticket for tomorrow :-/
22:39:16 <flo-retina> nhnt11: do the changes we made to the about patch bitrot the other patch aleth r+'ed?
22:39:17 <nhnt11> Btw, flo-retina, thanks for your patience in explaining the executeSoon stuff ;)
22:39:28 <nhnt11> I don't think so, no.
22:39:28 <flo-retina> np
22:39:32 <nhnt11> Let me just check fast
22:40:11 <qheaden> I'm going to install the official Yahoo! Messenger client on my other Windows machine, and see if it sends font tags. If not, I'll handle the tags later.
22:40:20 <nhnt11> flo-retina: Nope, it doesn't bitrot it
22:42:01 * nhnt11 is going to try hard to write daily logs from now on.
22:43:31 * flo-retina rebuilds with the new about patch
22:43:37 <flo-retina> and starts the build
22:43:49 <qheaden> Goodnight nhnt11
22:43:50 --> wnayes has joined #instantbird
22:44:11 <nhnt11> qheaden: I'll be here a bit longer, but good night! ;)
22:44:16 --> florian has joined #instantbird
22:44:19 <qheaden> :)
22:44:46 <florian> so the tab title is now empty until the page gets fully loaded?
22:44:52 <nhnt11> Yeah.
22:45:00 <florian> about:addons is slow to load
22:45:12 <nhnt11> It's faster the second time.
22:45:22 <florian> It's still very slow the third time
22:45:30 <florian> I'm on a debug build, they are much slower ;)
22:45:39 <nhnt11> Umm define slow?
22:45:44 <nhnt11> It's a split second for me.
22:45:49 <nhnt11> But I don't know about debug builds.
22:45:49 <florian> 1s
22:45:49 <nhnt11> :P
22:46:00 <nhnt11> It's more like... 200ms here.
22:46:12 <florian> it will be barely noticeable on a nightly
22:46:18 <florian> just slow because it's a debug build I think
22:46:22 <nhnt11> Cool..
22:47:06 <nhnt11> I find it funny that the favicon for the addons page is a mirror image of the puzzle piece images used as icons for addons.
22:47:08 <florian> (but I'm on a super fast computer, so it's possible my experience with a debug build is close to what a regular user on a random average bloatware ridden Windows computer would have ;)
22:47:41 <nhnt11> florian: I'm running OS X on a Dell machine from 2007. It's fast for me :P
22:47:56 <qheaden> nhnt11: Hackintosh?
22:47:59 <florian> could have been nice to set the title as about:<name> while loading
22:48:06 <nhnt11> (Also I likely have less than 100mb free ram right now)
22:48:15 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com)
22:48:16 <nhnt11> florian: I can get you a patch to do that in a second.
22:48:29 <florian> do you think it's worth it?
22:48:49 <nhnt11> I like little things.
22:48:52 <florian> if there's just one line to add to the file, I can also add it ;).
22:49:07 <nhnt11> Not one line unfortunately :(
22:49:11 <nhnt11> I need to use the tab property...
22:49:24 <florian> alright, don't bother then
22:49:28 <florian> we both need to go to bed
22:49:36 <nhnt11> Okay
22:49:37 <florian> and people with average computers don't even know commands exist ;)
22:49:42 <nhnt11> :P
22:49:54 <-- florian has quit (Input/output error)
22:50:00 <nhnt11> qheaden: Yes.
22:50:17 <qheaden> Cool.
22:51:10 <flo-retina> nhnt11: do you remember the number of that other bug?
22:51:14 --> Kaishi has joined #instantbird
22:51:27 <nhnt11> the selectpanel?
22:51:30 <nhnt11> bug 2012
22:51:32 <nhnt11> I think
22:51:33 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2012 min, --, ---, nhnt11, ASSI, Add method to select and focus a panel in tabbrowser
22:51:38 <nhnt11> Yeah.
22:51:45 <instantbot> florian@instantbird.org granted review for attachment 2520 on bug 2002.
22:51:50 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2002 enh, --, ---, nhnt11, NEW, Add an /about command to open the about:* pages
22:51:50 <flo-retina> thanks
22:52:05 <flo-retina> ah, it was in the checkin needed list anyway
22:55:24 <Kaishi> why isn't vertical tabs working anymore?
22:55:25 <Kaishi> :(
22:55:45 <nhnt11> Kaishi: A recent patch broke it :(
22:56:00 <flo-retina> I suspect nhnt11 knows who broke it ;)
22:56:07 <nhnt11> :P
22:56:17 <qheaden> When sending a message from the official Yahoo client, the message gets sent to my prpl twice. :-S
22:56:23 <Kaishi> it's the saddest thing
22:56:30 <nhnt11> Kaishi: Some changes which were unfortunately required for my GSoC project broke it.
22:57:09 <nhnt11> Hopefully clokep can fix it soon.. or I could probably help with it if he's busy.
22:57:13 <Kaishi> what's GSoC?
22:57:26 <nhnt11> Google Summer of Code.
22:59:17 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/52401d522970 - Nihanth Subramanya - Bug 2002 - Add an /about command to open the about:* pages, r=clokep,fqueze.
22:59:18 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/46ee5c836e48 - Nihanth Subramanya - Bug 2012 - Add method to select and focus a panel in tabbrowser, r=aleth.
23:00:20 <flo-retina> Kaishi: we have 3 students working full time on Instantbird this summer. :)
23:02:22 <flo-retina> nhnt11: you can mark these 2 bugs as fixed if you want (paste the checkin url, and set the target milestone)
23:02:26 <flo-retina> Good night :)
23:02:38 <nhnt11> Cool.
23:02:41 <nhnt11> Good night :)
23:04:45 <nhnt11> Should I set the status "Resolved FIXED"?
23:05:58 <instantbot> nhnt11@gmail.com set the Resolution field on bug 2012 to FIXED.
23:06:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2012 min, --, 1.5, nhnt11, RESO FIXED, Add method to select and focus a panel in tabbrowser
23:08:19 <instantbot> nhnt11@gmail.com set the Resolution field on bug 2002 to FIXED.
23:08:22 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=2002 enh, --, 1.5, nhnt11, RESO FIXED, Add an /about command to open the about:* pages
23:10:04 <instant-buildbot> build #408 of macosx-onCommit is complete: Failure [failed compile]  Build details are at http://buildbot.instantbird.org/builders/macosx-onCommit/builds/408  blamelist: Nihanth Subramanya <nhnt11@gmail.com>
23:14:48 * nhnt11 goes to bed.
23:14:50 <nhnt11> Good night.
23:19:08 <-- nhnt11 has quit (Quit: Instantbird 1.5a1pre -- http://www.instantbird.com)
23:25:22 <-- qlum has quit (Connection reset by peer)
23:34:49 --> clokep_wp8 has joined #instantbird
23:36:33 <clokep_wp8> Hopefully i can fix vertical tabs this weekend, but it won't happen tonight. :-)
23:36:45 <clokep_wp8> I accept patches though!
23:36:57 <-- clokep_wp8 has quit (Connection reset by peer)