All times are UTC.
00:29:07 --> billysanca has joined #instantbird 00:29:36 <-- billysanca has quit (Quit: Instantbird 1.2a1pre) 00:29:42 --> billysanca has joined #instantbird 00:46:28 <-- Tomek has quit (Quit: Instantbird 1.1) 00:55:44 * flo is testing a simple idea to speed up restoring convs on hold 01:12:42 <flo> hmm, I don't understand. I made some potentially slow code be executed once after displaying all messages instead of once per message... and it's now even slower :-/ 01:14:16 --> clokep has joined #instantbird 01:14:16 * ChanServ sets mode +h clokep 01:14:50 <-- clokep has quit (Quit: Instantbird 1.2a1pre) 01:14:58 --> clokep has joined #instantbird 01:14:58 * ChanServ sets mode +h clokep 01:16:02 <clokep> aleth: Btw I will review that code tomorrow. :) 01:36:24 <flo> Good night :) 02:15:26 <-- aleth has quit (Input/output error) 02:20:00 <-- clokep has quit (Quit: Instantbird 1.2a1pre) 02:56:39 <-- billysanca has quit (Quit: Instantbird 1.2a1pre) 04:15:28 --> habr100 has joined #instantbird 04:47:10 <-- habr100 has quit (Quit: Instantbird 1.2a1pre) 04:47:15 --> habr100 has joined #instantbird 05:48:40 --> clokep has joined #instantbird 05:48:40 * ChanServ sets mode +h clokep 05:52:58 <-- clokep has quit (Quit: Instantbird 1.2a1pre) 06:21:33 <-- habr100 has quit (Quit: Instantbird 1.2a1pre) 07:23:44 --> Mad_Maks has joined #instantbird 07:27:31 --> habr100 has joined #instantbird 08:11:06 <-- habr100 has quit (Ping timeout) 08:12:44 --> habr100 has joined #instantbird 09:20:27 --> jb has joined #instantbird 09:40:07 <-- habr100 has quit (Quit: Instantbird 1.2a1pre) 09:46:38 <-- jb has quit (Ping timeout) 10:08:57 --> Mic has joined #instantbird 10:08:57 * ChanServ sets mode +h Mic 10:09:57 --> jb has joined #instantbird 10:11:48 --> jb1 has joined #instantbird 10:12:23 <-- jb has quit (Ping timeout) 10:12:55 <-- jb1 has quit (Connection reset by peer) 10:21:59 --> aleth has joined #instantbird 10:22:53 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 10:23:02 --> aleth has joined #instantbird 10:24:29 <flo> when restoring a very large conversation (= takes 5s to appear) with the Simple message theme, Shark tells me that we spend 46% of the time executing JS regexp 10:33:30 <-- Mad_Maks has quit (Quit: Instantbird 1.2a1pre) 10:38:21 <aleth> Whoa. Do you know which, or what that encompasses? 10:38:49 <flo> I would love to know which regexp spends the time ;) 10:44:08 <flo> if I was doing a blind guess, I would bet on http://lxr.instantbird.org/instantbird/source/chat/modules/imThemes.jsm#468 10:45:00 <flo> but without the profiler, I wouldn't have guessed that the time is spent executing regexps, so (my) guesses are usually wrong for performance stuff ;) 10:46:07 <-- Mic has quit (Quit: Instantbird 1.2a1pre) 10:46:14 <aleth> Looks plausible though. 10:46:45 <aleth> Where did you find the profiler? Is it a mac-specific thing? 10:46:54 <flo> yes, it's a Mac tool 10:47:18 <flo> aleth: http://www.rotateright.com/index.html seems the equivalent for linux 10:48:02 <aleth> Ah, it's not JS specific then. 10:48:27 <flo> no :( 10:48:34 <flo> I don't have any JS profiler these days 10:49:04 <flo> if I had a JS profiler, I would know in which JS function the time is spent, so guessing which regexp is faulty would be trivial 10:49:25 <aleth> Yeah, that's why I asked initially. 10:50:47 <aleth> Thought you might have got some useful part of venkman working... 10:50:51 <flo> if only venkman still worked... ;) 10:51:01 <flo> heh, same idea ;) 10:57:02 <aleth> I don't understand the while loop in http://lxr.instantbird.org/instantbird/source/chat/modules/imThemes.jsm#476. Might it be optimized by pulling out the regex? 10:58:33 <flo> aleth: at each iteration the regexp matches the first %replacement% after the index replacementRegExp.lastIndex 11:00:58 <flo> if this regexp is actually where we are spending the time, we could optimize by matching the replacements in message style files only once per file and caching the result, instead of once per message as we currently do 11:01:12 <flo> the code would be more complicated though, so I would rather not do that if it's not where the time is spent 11:02:23 <flo> we have lots of other regexps that are executed for each message too. For each message we match emoticons, /me, nicks (I have the show nick add-on installed)... 11:04:28 <aleth> Yes, there are quite a lot once you start thinking about it... 11:05:23 <flo> the reason I thought about the message theme regexp is that it's the one that receives the largest input (as it doesn't get the (small) message text, but the whole HTML that's about to go into the conversation document 11:07:24 * flo tries venkman (without really expecting anything useful) 11:08:09 <aleth> If you disable that regex (which will mess things up), what's the performance increase? Or does it break things too much 11:09:12 <aleth> Probably just throws CSS errors all the time and takes much longer 11:09:26 <flo> you mean if I disable displaying messages? 11:10:21 <aleth> Just the parsing of %...% from the message style, which that regex seems to be doing 11:11:45 <flo> that would display %username% instead of nicks, %messageText% instead of the actual messages, etc... 11:11:48 <aleth> Oh that won't work 11:12:04 <aleth> Yes I just remembered about the message text also being a %..% 11:12:36 <flo> that may still "work" though (= lots of lines of HTML would still go in the conv window) 11:13:25 <aleth> Am not sure it would tell anything interesting anymore though 11:18:04 <flo> so I got some profiling data out of valgrind 11:18:34 <flo> but it spent as much time generating error while profiling as the executing the code I was trying to profile, so times may be completely off 11:19:05 <flo> and it has the very strange idea of sorting by file, then by time spent 11:20:35 <flo> s/valgrind/venkman/g 11:21:28 <flo> it thinks out of 5 seconds spent, I spent 775.33ms in replaceKeywordsInHTML 11:26:03 <aleth> about 30% of the regex time then, if the numbers are right 11:27:18 <aleth> Is it consistent? How much time does venkman think it is doing regex calls? 11:28:19 <flo> venkman won't tell anything about regexps 11:28:25 <flo> they are native code, not JS functions 11:29:29 <flo> aleth: if you want to look at Venkman's profile data: http://queze.net/goinfre/ib-profile.txt http://queze.net/goinfre/ib-profile.html 11:30:06 <flo> (I've never really been able to decide with of the txt and html format is the most usable (least unusable?) of the two) 11:31:43 <flo> my profile was apparently done on a conversation with ~ 200 messages 11:31:58 <flo> and 200 participants in the nicklist (it's also very slow to fill in that list :() 11:40:08 <aleth> Yes, nicklist filling takes a long time (joining #ubuntu is a useful demo). I doubt there are any easy wins there though, unless somehow filling the listbox "all at once" would save time. 11:40:41 <aleth> The listbox scrolling bug suggests to me the underlying code might just be slow. 11:42:14 <flo> "filling the listbox "all at once" would save time" what about the opposite? 11:42:58 <flo> handling the list of nicks in a simple JS object without the listbox, and putting in the listbox only the 30 first nicks, all at once, but after messages have appeared? 11:45:11 <flo> well, 30 would rather be as many as we can in less than 100ms 11:45:32 <flo> then continue on the next event loop spin 11:46:53 <flo> for the messages area, if we can't make it faster but can at least predict how much time it's going to take, we could do the work in small chunks to make the UI responsive, and display a progress bar 11:47:21 <flo> I would really prefer finding how to optimize it so that it can be fast though :) 11:51:03 <flo> hmm, OOo is unable to open CSV files containing decimal values, that's... interesting :-/ 11:53:12 <flo> hmm, it works better if one forces the locale to en-US :) 11:53:59 <aleth> Oh, do you use the 3.440,00 convention in France? 11:54:30 <aleth> For the message area, the 'infinite scroll' idea would eventually fix that (the html would only contain a limited number of messages at any time) 11:55:22 <aleth> Interesting idea regarding the listbox. 11:55:44 <flo> yes 11:56:04 <flo> but it's pretty obvious that if , is the field separator, it can't also be the decimal separator in the same file... 11:56:19 <aleth> But yeah, optimizing would be better. 11:56:22 <flo> taking most the values as strings, and some (2.02) as dates, is crazy too... 11:56:48 <aleth> Dates... bizarre. 11:56:56 <flo> especially as a date would certainly not be written this way in French 12:02:07 <aleth> Btw, for the Mac gestures, is creating a corresponding keyboard event in the gesture handler and dispatching it a reasonable solution there to avoid code duplication? Or is it better to get the conversation object via the DOM and call a shared 'scrolltotop' method there (which the keyboard event handler there then also calls). 12:04:11 <flo> what about adding scrollToNextSection/scrollToPreviousSection in convbrowser, and calling that for everything? 12:05:46 <aleth> I think scrollTo should be in convbrowser, but not scrollToFirstUnreadMessage, as convbrowser doesn't know where that is (that's in conversation) 12:07:57 <aleth> Of course one could move the requisite variable across to convbrowser too but that doesn't seem cleaner. 12:09:06 <aleth> But you have given me a different idea. 12:09:07 <flo> why? It's convbrowser that knows if the previous message was a context message 12:10:53 <aleth> You really think it's more efficient for convbrowser to go through some loop to find the first context message than the way the patch does it at the moment? 12:11:35 <aleth> That was the reason I put the code in conversation.xml in the first place. There's an obvious place there already where the last context message is added. 12:12:28 <aleth> But scrollToNextSection actually is a good idea, you could then press Alt-PgUp twice to get to the top of the messages 12:12:43 <aleth> That would be ideal. 12:13:52 <flo> "go through some loop to find the first context message" uh?? 12:15:28 <aleth> Or update some variable each time a context message is added, whatever 12:17:25 <instantbot> aletheia2@fastmail.fm cancelled review?(clokep@gmail.com) for attachment 1032 on bug 1032. 12:17:27 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1032 enh, --, ---, nobody, NEW, Scroll to first unread message when opening hidden conversation 12:17:35 <flo> or do it only once, the first time a non-context message is added? 12:19:37 <aleth> Either way it seems smarter to me to do it in conversation.xml, where there is _already_ a variable tracking just that. But I've come around to storing the info in convbrowser, because the 'jump to next/previous' section idea is clearly much better. 12:20:30 <flo> aleth: the info is already in convbrowser 12:20:47 <flo> see the this._lastMessageIsContext thing 12:21:11 <flo> (it needs to become true by default, btw) 12:21:53 <aleth> OK, I'll take another look when I redo it. 12:25:35 <aleth> Btw, does the getBrowser() call in the mouse gesture handler return the tabbrowser or the message browser? 12:27:50 --> igorko has joined #instantbird 12:31:07 --> igorko1 has joined #instantbird 12:31:08 <aleth> (i.e. is it the getBrowser() in instantbird.js) 12:31:16 <-- igorko has quit (Ping timeout) 12:35:47 <flo> tabbrowser I think 12:36:00 <flo> that getBrowser is implemented in instantbird.js so you can check :) 12:50:57 <-- igorko1 has quit (Quit: Instantbird 1.1) 12:56:03 <instantbot> New Instantbird (UI) bug 1187 filed by kevin.gadd@gmail.com. 12:56:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1187 cri, --, ---, nobody, UNCO, Severe pauses/hang when dealing with large conversation backlogs 13:20:45 <aleth> Looking at your venkman output, it's really noticeable how slow the listbox calls are, considering. I wonder why? e.g. 500ms spent on getItemAtIndex... why does that take so long? 13:35:26 <aleth> maybe of interest http://blog.tuenti.com/dev/tips-and-tricks-with-regular-expressions-in-js/ 13:37:04 <aleth> e.g. |replacementRegExp = /%([a-zA-Z]*)(\{([^\}]*)\})?%/g;| -> |replacementRegExp = /%([A-Z]*)(\{([^\}]*)\})?%/gi;| might be faster 13:46:17 --> mmkmou has joined #instantbird 13:48:08 <-- mmkmou has quit (Ping timeout) 13:50:56 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 14:00:36 --> aleth has joined #instantbird 14:04:15 --> mmkmou has joined #instantbird 14:11:57 <aleth> plus, maybe using the y flag rather than g? 14:12:19 <aleth> (can't test these myself due to lack of profiler etc) 14:13:57 <flo> aleth: the profiler doesn't really help to compare the different times either 14:14:05 <flo> as you need to have the same conversation to test with, etc... 14:16:56 <-- mmkmou has quit (Ping timeout) 14:17:23 --> mmkmou has joined #instantbird 14:17:23 <aleth> Hmm, yes, that makes it tricky, as you don't have a stable test case. 14:33:16 <-- chrisccoulson has quit (Ping timeout) 14:52:21 --> Plop has joined #instantbird 14:55:38 <-- BlueMaxima has quit (Quit: Instantbird 1.1) 15:47:56 --> Mic has joined #instantbird 15:47:57 * ChanServ sets mode +h Mic 16:08:37 <-- Even1 has quit (Ping timeout) 16:18:42 --> mikk_s has joined #instantbird 16:18:46 <-- mikk_s has quit (Quit: mikk_s) 16:24:56 --> Tomek has joined #instantbird 16:28:24 <-- mmkmou has quit (Ping timeout) 16:44:05 --> mmkmou has joined #instantbird 16:45:15 --> devfil has joined #instantbird 16:59:40 <flo> "InstantBird's UI thread hangs for around 2-3 minutes while repopulating the 16:59:41 <flo> backlog." (bug 1187). Wow! 16:59:44 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1187 cri, --, ---, nobody, UNCO, Severe pauses/hang when dealing with large conversation backlogs 17:08:10 <Mic> The reporter is Mozilla employee btw 18:05:53 <flo> aleth: ah, I didn't think of that detail about resizing. (I did think that keeping the position rather than the element we want to scroll into view wasn't a great idea though!) 18:06:45 <aleth> It didn't matter for the original goal of just scrolling there once on opening ;) 18:07:35 <flo> right 18:07:36 <flo> :) 18:07:58 <aleth> feature creep ;) 18:09:42 <aleth> In a good way... 18:12:25 <aleth> Actually it's probably a good sign people are using IB for IRC to the extent that they accrue backlogs that take 2-3 minutes to open :) 18:12:53 <aleth> and wasn't that reported before, for twitter searches 18:15:32 <-- mmkmou has left #instantbird () 18:19:40 <flo> i think a solution is to advise these people to use nightlies :-P 18:19:57 <flo> daily update (-> restart), no more 2-3 days backlogs :-P 18:22:53 <aleth> perfect :) 18:23:33 <Mic> lol 18:25:22 <flo> It's what I do, by the way. 18:25:36 <flo> when we don't build nightlies for a few days, I'm more annoyed by the memory usage ;) 18:26:12 <Mic> I don't mind starting and shutting down the computer when I need or don't need it. 18:26:44 <flo> I don't see how it could be a useful action 18:27:49 <flo> I just close my laptop's screen to put it to sleep when I don't use it. When I reopen the screen it's ready to use again (to be fair, there's probably a 2-3 seconds delay here). 18:28:09 <flo> it's a bit different with desktop PCs of course 18:28:27 <aleth> Having things on standby draws quite a bit of power in aggregate 18:29:03 <flo> it can stay on the battery during that time 18:29:08 <aleth> Laptops are more optimized for that kind of thing I guess 18:29:43 <Mic> If you need it that quickly then OK. I tend to know in advance when I'll need it and just press the power button first thing when I come to the room. 18:29:51 <aleth> But generally speaking, devices that are not in use should not be consuming power, just on general principle 18:30:00 <aleth> Everything else is just bad engineering 18:30:27 <Mic> flo: power drawn from the battery doesn't count as power consumption? ;) 18:30:59 <flo> Mic: I just meant it's a minimal amount 18:31:08 <Mic> For me it's just natural to start and shutdown as I need it. Like pressing the light switch when I leave the room 18:31:18 <aleth> Same here 18:31:30 <flo> Mic: it's natural for me too 18:31:31 <Mic> OK, that one won't be that necessary now that we have the power saving lamps 18:31:45 <flo> but it's also natural than when I "tell" it I'm ready to use it, it should be ready to be used. 18:32:01 <aleth> flo: yes, that's what I meant by it being an engineering problem 18:32:03 <flo> The light switch doesn't have a progress bar telling me it will be ready to light the room in a minute 18:32:31 <flo> closing/opening the screen feels a lot more like flipping the light switch, by the way 18:32:51 <aleth> that's not the part that's bad design ;) 18:33:40 <flo> yeah 18:33:53 <-- Mic has quit (Ping timeout) 18:34:24 <flo> the poor design is that a PC (even a relatively fast one with a decent operating system) takes more time to turn itself on and be ready to use than I need time to either forget what I wanted to do, or grab my laptop and starting doing something else. 18:36:18 <flo> I think it would make sense to have something like some flash memory of the same size as the RAM that could receive the content of the RAM when the machine shutdown (quickly!), and then restarting would just turn the screen on. Any RAM access would lazily fetch the relevant data in the flash memory 19:19:38 <aleth> It's actually surprising that hasn't been done, considering how relatively cheap flash memory is 19:20:09 --> chrisccoulson has joined #instantbird 19:47:03 <-- micahg_ has quit (Connection refused) 19:47:13 --> micahg_ has joined #instantbird 19:47:58 --> EionRobb has joined #instantbird 20:07:53 --> billysanca has joined #instantbird 20:23:27 --> franksouza183 has joined #instantbird 20:23:41 <franksouza183> aleth 20:24:15 <franksouza183> someone online? 20:24:50 <aleth> yes 20:24:55 <aleth> hi 20:24:55 <franksouza183> ow 20:24:59 <franksouza183> hi 20:25:41 <franksouza183> Well I'm finishing that theme for adium instantbird, but I can not register on the site of addons 20:26:01 <franksouza183> the site does not send me the confirmation email 20:26:28 <aleth> That shouldn't happen :( 20:26:29 <franksouza183> I tried several times already waited hours, but so far nothing 20:26:55 <aleth> need to ping Even or flo who know more about that site's internals 20:27:20 <aleth> It worked for me... 20:28:57 <franksouza183> well, I'am getting porting that theme successfully to instantbird, and eventually contribute to a own theme for instantbird 20:29:07 <aleth> sounds great! :) 20:30:00 <franksouza183> I will wait to resolve the site issue 20:30:06 <aleth> You may also like to try it with the current nightly 20:30:25 <aleth> Stay in this room for a bit and someone will show up to help 20:30:33 <franksouza183> ok 20:30:37 <franksouza183> thanx 20:31:17 <franksouza183> otherwise 20:31:29 <franksouza183> I'm not using that script 20:31:40 <franksouza183> it fails always here 20:31:58 <aleth> What script? 20:32:01 <franksouza183> estou fazendo e testando manualmente 20:32:18 <franksouza183> one that converts adium themes 20:32:20 <aleth> Doing it manually is easier anyway I think... 20:32:41 <aleth> (Guessing from the message style I edited the conversion does not polish things for you) 20:33:04 <franksouza183> exactly 20:33:32 <franksouza183> a more positive point to doing manually 20:33:40 <aleth> One thing it doesn't add for example is support for nick colors in MUCs 20:34:23 <franksouza183> have any theme available that use this feature? 20:34:57 <franksouza183> I will study it 20:35:01 <aleth> The standard ones? And minimal2 for example? 20:35:10 <franksouza183> hum 20:35:13 <franksouza183> ok 20:35:33 <aleth> For the bubbles theme, the bubble color corresponds to the nick color 20:35:49 <franksouza183> huu 20:35:51 <aleth> It's more obvious with the new nightly nicklist 20:35:52 <franksouza183> o.O 20:36:15 <aleth> For the other default themes, they also do something with the color info 20:36:42 <franksouza183> ok, I'll check this 20:37:03 <aleth> It's just a matter of sticking %sendercolor% in the right place as far as I remember 20:37:25 <aleth> Though the Bubbles theme does something more elaborate with javascript 20:38:24 <franksouza183> what color format? 20:38:27 <franksouza183> hex ?? 20:38:29 <franksouza183> #000000 20:38:41 <franksouza183> that's it ? 20:39:00 <aleth> I think it's passed as a CSS style 20:39:09 <aleth> color: rgb(...) 20:39:10 <aleth> something like that 20:39:16 <franksouza183> huj 20:39:24 <franksouza183> good 20:39:53 <franksouza183> otherwise 20:40:15 <franksouza183> This version of gecko is used by which version of firefox? 20:40:47 <aleth> Have a look in the about box 20:40:57 <franksouza183> yeahh 20:41:00 <aleth> Gecko 9 = Firefox 9 20:41:08 <franksouza183> ow 20:41:10 <franksouza183> ok 20:41:16 <aleth> I think 1.1 is Gecko 7 20:41:27 <franksouza183> yes 20:41:35 <aleth> 1.2 is Gecko 9 atm 20:42:07 <franksouza183> so it is easier to test on-firefox 20:42:24 <franksouza183> nightly ? 20:42:25 <franksouza183> 9 ? 20:42:28 <-- billysanca has quit (Quit: Instantbird 1.2a1pre) 20:42:29 <aleth> If it helps you... 20:42:35 --> billysanca has joined #instantbird 20:42:42 <aleth> Firefox beta is 9 at the moment I think 20:42:57 <franksouza183> no, sorry 20:43:05 <franksouza183> IB nightly is 9 ?? 20:43:11 <aleth> Yes 20:43:14 <franksouza183> ok 20:43:57 <aleth> Are you using Firefox to test message styles? 20:44:09 <aleth> I always did it directly in IB 20:44:33 <franksouza183> aways on firefox 20:44:46 <franksouza183> 7 20:44:52 <franksouza183> ops 20:44:54 <franksouza183> sorry 20:44:56 <franksouza183> 8 20:45:05 <aleth> Shouldn't matter really 20:45:15 <aleth> Unless you are using some really new features ;) 20:45:26 <franksouza183> exactly 20:45:53 <franksouza183> as svg masking and clipping 20:46:19 <aleth> Did that change from 7 to 8? 20:46:38 <franksouza183> no no 20:46:53 <franksouza183> it's since 3.5 ++ 20:47:30 <franksouza183> sorry 20:47:34 <franksouza183> "Unless you are using some really new features " 20:47:46 <franksouza183> I understand now 20:47:52 <franksouza183> :) 20:48:46 <franksouza183> I see other new features introduced since version 4 20:49:16 <aleth> Yes you can use all new the HTML5 stuff for example 20:49:27 <franksouza183> I will try to introduce on theme 20:49:30 <aleth> The bubbles message style does some clever things by the way, like the collapsing system messages 20:49:39 <franksouza183> Yes, I thought that too 20:50:30 <aleth> If you use something really cutting edge, you just have to mark the compatibility of the add-on accordingly 20:50:53 <franksouza183> yes 20:51:05 <franksouza183> I see that 21:31:39 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 21:32:51 --> aleth has joined #instantbird 21:33:09 <-- Tobin has quit (Quit: Everything you do is to hurt me, leave me alone.) 21:33:25 --> Tobin has joined #instantbird 21:34:24 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 21:35:24 --> aleth has joined #instantbird 21:38:07 --> Even1 has joined #instantbird 21:57:28 <flo> franksouza183: have you checked if the email is in your spam folder? 21:57:40 <franksouza183> ops 21:57:44 <franksouza183> one minute 21:58:03 <franksouza183> yes 21:58:05 <franksouza183> its here 21:58:09 <franksouza183> thenx 21:58:11 <franksouza183> thanx 21:59:47 <-- billysanca has quit (Quit: Instantbird 1.2a1pre) 21:59:57 --> billysanca has joined #instantbird 22:01:47 <-- Plop has quit (Ping timeout) 22:02:07 --> Plop has joined #instantbird 22:02:25 --> clokep has joined #instantbird 22:02:25 * ChanServ sets mode +h clokep 22:16:35 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 22:16:37 --> aleth has joined #instantbird 22:18:12 <clokep> You midaired my flo. :P 22:18:18 <clokep> *me rather. 22:18:40 * flo wondered who was "your flo" that I could be mid airing with 22:19:17 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 22:19:23 --> aleth has joined #instantbird 22:20:53 <flo> clokep: I think this will also depend on bug 692 22:20:56 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=692 enh, --, ---, nobody, NEW, redesign the purpleIMessage xpcom interface 22:21:09 <clokep> flo: Yes, that would probably help! 22:21:45 <flo> if we separate the prplIMessage interface that protocol plugins need to implement from an imIMessage interface that the UI uses, we can get smarter and cache some things 22:22:43 --> hunsly has joined #instantbird 22:23:23 <franksouza183> aleth: I would like to test the theme? 22:23:49 <flo> the difficulty with caches though, is that we need to be able to invalidate them when some preferences change 22:23:55 <aleth> franksouza183: Can't you just install it from the add-ons manager? 22:24:13 <aleth> Click the little toolbox and "install from file" 22:24:37 <aleth> (Experimental add-ons can't be found via the search box) 22:24:48 <franksouza183> no, I'm asking if you want to test the theme 22:24:55 <aleth> Oh ok :) 22:24:59 <aleth> link please? 22:25:07 <franksouza183> I'll send to you 22:25:09 <franksouza183> 1 min 22:26:50 <franksouza183> sent 22:27:02 <aleth> OK, I thought you had it on the add-on site 22:28:14 <franksouza183> not yet, waiting to release a more stable 22:28:25 <flo> has someone ever tried to reproduce bug 1140? 22:28:32 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1140 maj, --, ---, nobody, UNCO, Ctrl+F search in a conversation window with a long backlog hangs Instantbird 22:28:52 <aleth> franksouza183: It would be nice if it was marked compatible with 1.2a1pre 22:29:00 <aleth> (I am doing that by hand) 22:29:23 <franksouza183> ok 22:29:39 <aleth> flo: bug 1187? 22:29:44 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1187 cri, --, ---, nobody, NEW, Severe pauses/hang when dealing with large conversation backlogs 22:29:51 <aleth> (comment 1) 22:30:01 <aleth> sorry, description 22:30:10 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 22:30:15 --> aleth has joined #instantbird 22:30:16 <flo> aleth: both bugs have been filed by the same person. 22:30:21 <aleth> oops, my bad 22:31:05 --> Mic|web has joined #instantbird 22:31:13 <Mic|web> Good evening 22:31:31 <franksouza183> aleth: <em:minVersion>0.2a1pre</em:minVersion> 22:31:33 <franksouza183> <em:maxVersion>1.2a1pre</em:maxVersion> 22:31:37 <franksouza183> thats it ? 22:32:03 <franksouza183> sorry 22:32:05 <aleth> You probably want minVersion 1.0, better 1.1 if you don't actually test it on 1.0 22:32:07 <franksouza183> is this? 22:32:12 <franksouza183> ok 22:32:43 <franksouza183> <em:minVersion>1.1</em:minVersion> 22:32:45 <franksouza183> <em:maxVersion>1.2a1pre</em:maxVersion> 22:32:46 <franksouza183> ok? 22:33:10 <aleth> It should probably be 1.1a1pre 22:33:40 <franksouza183> <em:minVersion>1.1a1pre</em:minVersion> 22:33:55 <aleth> OK 22:34:00 <franksouza183> ok 22:36:08 <Mic|web> flo: is there a sure way to know when a conversation is fully restored and reactive? 22:36:29 <Mic|web> Automatically, I mean? 22:42:41 <Mic|web> hmm, gtg. Good night :) 22:42:48 <-- Mic|web has quit (Quit: http://www.mibbit.com ajax IRC Client) 22:50:37 <-- aleth has quit (Quit: Instantbird 1.2a1pre) 22:50:42 --> aleth has joined #instantbird 23:05:48 <franksouza183> aleth: thanks 23:11:48 <aleth> I just looked at the stats for the minimal2 message style. It seems there are still daily users of IB on version 0.2 (around 1%), and a slightly larger though declining number on 1.0. 23:13:06 <franksouza183> on version 0.2, what gecko version 23:13:10 <franksouza183> ? 23:13:53 <aleth> franksouza183: Nobody should still be using Instantbird 0.2, that's why it's surprising 23:14:06 <franksouza183> hum 23:14:42 <-- devfil has quit (Client exited) 23:15:28 <franksouza183> then it is good idea make it impossible to 0.2 23:15:35 <franksouza183> upgrade forced 23:15:40 <franksouza183> :) 23:16:00 <aleth> It's not trivial to make that happen, but I think it is being worked on 23:53:08 <flo> "23:36:08 - Mic|web: flo: is there a sure way to know when a conversation is fully restored and reactive?" I don't know what you mean. A sure way from what? 23:53:13 <flo> from the code in conversation.xml, it's trivial 23:53:48 <flo> aleth: I found today that there was still 0.2b2 on my mother's laptop 23:54:01 <flo> built in March 2010... 23:54:16 <flo> and Firefox 3.6.4, from April 1st (2010)! 23:54:26 <aleth> Mic: Did you mean "is there an event that fires after all the existing messages have been displayed"? 23:54:40 <aleth> flo: vintage! 23:54:58 <flo> a few months ago I found 0.1.2 on my father's computer ;) 23:55:27 <aleth> I think nothing on my parents computer updates unless it is automatic ;) 23:55:55 <flo> aleth: isn't _textSelected a boolean? 23:56:19 <aleth> where was that? 23:56:19 <flo> she didn't want to update Firefox 23:56:29 <flo> aleth: https://bugzilla.instantbird.org/attachment.cgi?id=1026 23:57:33 <aleth> flo: If I remember correctly, it's a boolean *after* it's been initialized. null means it has not been initialized yet. The original code checks for existence of the property instead. 23:57:37 <flo> because the download button said "Windows ⢠8.0.1 ⢠Français" and she said "it's not for me, I don't have Windows 8" and closed the window 23:58:11 <aleth> flo: oh dear :( great story though! 23:58:23 <flo> |false != null| -> false 23:58:36 <aleth> Just goes to show how details matter on these messages 23:58:36 <flo> aleth: yeah, I think I'll tell about it to some Mozilla people ;) 23:59:44 <flo> oop 23:59:49 <aleth> flo: |false != null| is true in the error console at least 23:59:52 <flo> "|false != null| -> false" forget that line please :) 23:59:54 <aleth> I did check..