All times are UTC.
00:09:38 <-- PingWiN has quit (Ping timeout: 121 seconds) 00:11:43 --> Alex2 has joined #instantbird 00:24:49 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 00:32:43 <-- Bollebib has quit (Ping timeout: 121 seconds) 01:01:00 <-- aleth has quit (Quit: :tiuQ) 01:13:14 <-- arlolra has quit (Client exited) 01:23:44 --> clokep has joined #instantbird 01:23:45 * ChanServ sets mode +o clokep 01:30:19 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 01:30:28 --> clokep has joined #instantbird 01:30:28 * ChanServ sets mode +o clokep 01:35:15 <-- myk has quit (Ping timeout: 121 seconds) 02:21:05 --> rohandalvi has joined #instantbird 02:22:38 <-- rohandalvi has quit (Quit: ) 02:54:43 <-- mikef has quit (*.net *.split) 02:54:43 <-- Fallen has quit (*.net *.split) 02:54:50 --> mikef has joined #instantbird 02:54:50 --> Fallen has joined #instantbird 03:37:12 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 04:47:08 <instant-buildbot> build #507 of linux64-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/507 04:47:35 <instant-buildbot> build #1806 of win32-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1806 04:59:30 <instant-buildbot> build #2974 of macosx-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2974 06:05:38 <-- EionRobb has quit (Quit: Leaving.) 06:14:11 --> myk has joined #instantbird 06:38:19 * MattATobin is now known as Tobin 06:59:09 --> EionRobb has joined #instantbird 07:38:00 --> mpmc has joined #instantbird 07:58:53 <-- myk has quit (Ping timeout: 121 seconds) 08:36:05 --> BWMerlin has joined #instantbird 09:26:13 <-- nhnt11 has quit (Ping timeout: 121 seconds) 09:41:47 --> nhnt11 has joined #instantbird 09:41:47 * ChanServ sets mode +h nhnt11 09:48:08 --> Bollebib has joined #instantbird 09:52:30 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 10:00:20 <-- EionRobb has quit (Quit: Leaving.) 10:05:06 <-- Tonnes has quit (Connection closed) 10:09:59 <-- nhnt11 has quit (Ping timeout: 121 seconds) 10:13:56 <-- Alex2 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 10:23:04 --> flo-retina has joined #instantbird 10:23:05 * ChanServ sets mode +qo flo-retina flo-retina 10:37:52 --> nhnt11 has joined #instantbird 10:37:52 * ChanServ sets mode +h nhnt11 10:45:57 <-- nhnt11 has quit (Ping timeout: 121 seconds) 10:46:46 --> nhnt11 has joined #instantbird 10:46:46 * ChanServ sets mode +h nhnt11 10:50:12 --> freaktechnik_ has joined #instantbird 10:50:29 --> pWnnn has joined #instantbird 10:51:55 <-- freaktechnik has quit (Ping timeout: 121 seconds) 10:51:55 * freaktechnik_ is now known as freaktechnik 10:52:54 <-- nhnt11 has quit (Ping timeout: 121 seconds) 11:25:03 --> clokep has joined #instantbird 11:25:03 * ChanServ sets mode +o clokep 11:27:03 <freaktechnik> yay, ircHandlers.unregisterHandler doesn't unregister it. Weird. 11:27:26 <freaktechnik> oh, I see why 11:27:27 <freaktechnik> <_< 11:27:29 <freaktechnik> >_> 11:28:04 <freaktechnik> so to unregister, one is expected to do |ircHandlers._ircHandlers = ircHandlers.unregisterHandler(aHandler)| 11:28:32 <freaktechnik> clokep is that intended? 11:28:51 --> clokep_ has joined #instantbird 11:28:51 * ChanServ sets mode +o clokep_ 11:30:45 <freaktechnik> wait, no 11:30:46 <freaktechnik> wut 11:30:49 <freaktechnik> I is confused 11:31:50 <-- clokep has quit (Ping timeout: 121 seconds) 11:32:08 --> clokep has joined #instantbird 11:32:08 * ChanServ sets mode +o clokep 11:32:35 <freaktechnik> huh, so all I know is that unregisterHandler doesn't work, as in the array is unmodified. But I don't see why. Aren't arrays passed by reference? 11:32:54 <-- clokep_ has quit (Ping timeout: 121 seconds) 11:34:33 <clokep> freaktechnik: That is not the intention. 11:35:11 <freaktechnik> clokep: all I have observed so far, is that the handlers array is unmodified after calling unregister... 11:35:42 <freaktechnik> so I assume the _unregisterHandler change to aArray doesn't affect the actual array. But that's not how I remember JS working... 11:36:01 <clokep> That is how it should work, yeah. 11:40:45 <clokep> Unless someone is making a copy of the Array somewhere. 11:41:50 <freaktechnik> all I can say, is that doing |irchHandlers._ircHandlers = ircHandlers._ircHandlers.filter((h) => h.name != handlers.name)| works as you'd expect. 11:42:31 <clokep> Hmm....maybe filter doesn't modify the array and returns a new one 11:42:37 <freaktechnik> it does 11:42:52 <clokep> Well that's going to be the problem... 11:43:03 <freaktechnik> but _unregisterHandler does |aArray = aArray.filter((h) => h.name != aHandler.name)| 11:43:22 <freaktechnik> oh, wait, I understand now 11:43:29 <freaktechnik> I think 11:43:30 <clokep> Yeah that just reassigns the variable. 11:43:34 <freaktechnik> yup 11:43:39 <clokep> https://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircHandlers.jsm#66 should be the line you gave. 11:43:41 <freaktechnik> I'll qnew and fix it... 11:43:45 <clokep> (And all the similar lines) 11:43:58 <freaktechnik> https://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircHandlers.jsm#59 11:44:02 <clokep> Also...I hav eno idea why those *return* something. 11:44:04 <freaktechnik> should return 11:44:16 <freaktechnik> because register returns true or false depending on success 11:44:24 <clokep> Ah. 11:44:38 <clokep> Yes, that method should return so the callers can assign it back to this._<something> 11:45:04 <freaktechnik> also, is it by design that you can register multiple handlers with the same name? 11:45:12 <freaktechnik> so you can have multiple prios under the same name? 11:47:47 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 11:47:49 --> clokep has joined #instantbird 11:47:50 * ChanServ sets mode +o clokep 11:48:41 --> clokep_ has joined #instantbird 11:48:41 * ChanServ sets mode +o clokep_ 11:48:54 <clokep_> freaktechnik: The name is just ther eto help you debug. 11:49:09 <freaktechnik> and to unregister 11:49:25 <freaktechnik> unregistering goes by name 11:49:34 <freaktechnik> because that's the only identifier there is... 11:49:58 <clokep_> It's probably the intention that it's unique, yes. 11:50:14 <clokep_> That code would probably be simpler w/ a Map, which didn't exist when I wrote it. :P 11:50:20 --> aleth has joined #instantbird 11:50:20 * ChanServ sets mode +o aleth 11:50:41 <freaktechnik> I'm asking this, because I'm currently registering some of the base IRC handlers which I then just leak 11:50:51 <freaktechnik> because unregistering would break other IRC accounts... 11:51:53 <-- clokep has quit (Ping timeout: 121 seconds) 11:51:53 * clokep_ is now known as clokep 11:56:03 <instantbot> New Chat Core - IRC bug 1225454 filed by martin@humanoids.be. 11:56:04 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1225454 tri, --, ---, nobody, UNCO, Unregistering IRC handlers doesn't work 11:56:48 <clokep> Why are you registering them twice? 11:56:59 <clokep> So...that probably has unintended consequences. 11:57:06 <freaktechnik> the second time happens by instantbird 11:57:26 <freaktechnik> and yes it has, if my handlers get sorted before the builtin ones and the extension gets unloaded. 11:57:55 <clokep> Some of the built-in handlers do stuff and then return False to fall through to other handlers. 11:58:01 <freaktechnik> yes 11:58:02 <clokep> This could cause a handler to do something twice. 11:58:12 <clokep> So registering the same handler multiple times is a Bad Idea. 11:58:13 <freaktechnik> the problem is, the built in handlers aren't registered if there's no IRC account 12:00:30 <clokep> They're registered when the first one is instantiated, I think. 12:01:10 <clokep> (And depending on the order of accounts being initialized sounds like a bad idea btw. :-D) 12:01:22 <freaktechnik> well, whenever the protocol is constructed 12:01:44 <freaktechnik> hm, I just realized unloading is no problem, because Arrays hold strong references, right? 12:02:03 <freaktechnik> hmm, though contexts sometimes get nuked for extensions :S 12:02:07 <clokep> So to be clear, you have a protocol which inherits from IRC but then adds additional extensions? 12:02:18 <clokep> So it uses the IRC handlers, but then registeres as a separate prpl? 12:04:26 * clokep was wondering how hard it would be to instantiate your own handlers object... 12:04:33 <clokep> But that's a singleton and totally not designed for that. 12:05:53 * aleth is a bit confused by this discussion 12:06:25 <aleth> If the list of handlers is shared too, won't that mess up IRC? 12:06:31 <freaktechnik> nope 12:06:36 <freaktechnik> isEnabled can check for the protocol 12:06:43 <clokep> I'll be back in an hour. 12:06:46 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 12:07:41 <freaktechnik> I guess what I could do is "clone" the base IRC handlers I need and rename them and add my isEnabled. 12:13:55 <freaktechnik> I think this'll work 12:13:56 <freaktechnik> https://github.com/freaktechnik/twitch-provider/blob/master/lib/twitch/handlers.js#L225-L237 12:14:09 <freaktechnik> well, if anything gets executed twice it's my problem. 12:20:23 <aleth> do twitch chat participants have avatars? 12:23:10 <-- BWMerlin has quit (Client exited) 12:25:40 --> Tonnes has joined #instantbird 12:26:27 <freaktechnik> aleth: yes :) 12:26:42 <aleth> freaktechnik: have you added them to the tooltips yet? ;) 12:29:26 --> nhnt11 has joined #instantbird 12:29:26 * ChanServ sets mode +h nhnt11 12:29:44 <freaktechnik> aleth: https://github.com/freaktechnik/twitch-provider/blob/master/lib/twitch/participant.js#L24 -> https://i.imgur.com/K1RpObj.png 12:29:59 <aleth> nice :-) 12:30:04 <freaktechnik> (and uh yes, that tooltip coloring is a GTK3 bug) 12:30:08 <aleth> Does it use the IRC AVATAR extension? 12:30:18 <freaktechnik> nope 12:30:23 <freaktechnik> REST APIU 12:30:29 <aleth> ah 12:31:04 <freaktechnik> the IRC tags only contain so much info 12:31:19 <freaktechnik> but they still contain more than I can currently display with instantbird (-> message colors and stuff) 12:31:23 <freaktechnik> but that's low prio atm 12:52:36 --> clokep_work has joined #instantbird 12:52:36 * ChanServ sets mode +o clokep_work 12:53:26 <-- aleth has quit (Ping timeout: 121 seconds) 12:54:09 <freaktechnik> clokep_work: I've fixed it by "cloning" the IRC base and CAP handlers and only activating them for my prpl. So if something goes wrong it only affects my prpl. 12:57:11 --> aleth has joined #instantbird 12:57:11 * ChanServ sets mode +o aleth 13:00:19 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 13:00:27 <clokep_work> freaktechnik: That's one way to do it. ;) 13:02:24 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 13:09:54 --> Bollebib has joined #instantbird 14:07:31 <instantbot> New Chat Core - IRC bug 1225468 filed by florian@queze.net. 14:07:33 --> instantbot has joined #instantbird 14:07:33 topic changed by fripp.mozilla.org to "Ask about Instantbird (http://instantbird.com) here! :-) | Current version is Instantbird 1.5 | News: http://blog.instantbird.org | Nightlies: http://nightly.instantbird.im (for testing only) | IRC logs: http://log.bezut.info | Pastebin: http://pastebin.instantbird.org | Bugs: https://bugzilla.mozilla.org" 14:07:33 * ChanServ sets mode +v instantbot 14:09:19 <-- aleth has quit (Ping timeout: 121 seconds) 14:12:02 <clokep_work> freaktechnik: Sorry you've hit so many edge-cases. :) 14:12:16 <freaktechnik> It's fun to hit the edge cases ;) 14:12:34 <freaktechnik> though the "add-on SDK not getting the background frame on startup" edge case will be not so fun to fix 14:14:51 <flo-retina> isn't the add-on SDK an edge case in itself? 14:18:32 <freaktechnik> these days, yes 14:29:34 <-- flo-retina has quit (Ping timeout: 121 seconds) 14:29:52 --> flo-retina has joined #instantbird 14:29:53 * ChanServ sets mode +qo flo-retina flo-retina 14:30:28 <-- Morian has quit (Ping timeout: 121 seconds) 14:30:47 <-- redDragon has quit (Ping timeout: 121 seconds) 14:38:16 --> redDragon has joined #instantbird 14:44:44 --> Morian has joined #instantbird 14:55:10 --> myk has joined #instantbird 15:01:03 <-- Morian has quit (Ping timeout: 121 seconds) 15:01:04 --> Morian has joined #instantbird 15:18:00 --> aleth has joined #instantbird 15:18:00 * ChanServ sets mode +o aleth 15:51:47 --> MikkCZ has joined #instantbird 15:56:45 <-- myk has quit (Ping timeout: 121 seconds) 17:05:40 <MikkCZ> Hi. I noticed the chat l10n folder is identical with Thunderbird chat folder, maybe also other single files are same in both products. If there is some list of them, it would make the translation easier but also help me to keep it up to date and terminologicaly unified with TB/FF. Wouldn't be possible to use the one from Thunderbird repository? Also are there any plans to add Instantbird for localization via Pontoon.Mozilla.org. 17:06:39 <aleth> MikkCZ: good question! 17:06:56 <flo-retina> I don't know pontoon.mozilla.org. I discussed with someone working on mozilla l10n whether it would be possible to have the im/ folder in the standard mozilla l10n repository. The answer was "probably yes" but it wasn't a definitive answer. 17:06:58 <aleth> IB l10n is definitely going to change for the next release (which is the first since the move to com-central) 17:08:37 <aleth> chat/ certainly shouldn't have to be localized twice 17:09:15 <MikkCZ> If the Instantbird l10n is moved into hg.mozilla.org, no problem with that if we do not loose anything. I've already make sure both IB and TB have the same chat files localization. 17:09:51 <flo-retina> taking the chat/ folder from the mozilla localization shouldn't be difficult (we already take toolkit/ etc... from there) 17:10:20 <flo-retina> ideally what would be really interesting is to stop having our own set of l10n repositories 17:11:08 <MikkCZ> Pontoon is quite nice in the way it enables localization of every project Mozilla offers in one system (websites, AMO, products). If Instantbird l10n is moved to Mozilla repositories, there should be IMO no blocker for adding to Pontoon. Maybe it would be possible for the current state too. 17:11:44 <flo-retina> I haven't been able to spend much time on all the l10n stuff unfortunately 17:11:58 <flo-retina> until we get a full set of nightly builds, it's difficult to consider releasing. 17:12:05 <flo-retina> I'll focus on l10n when attempting to make beta builds. 17:12:34 <MikkCZ> Great. :) 17:38:51 --> Mnyromyr has joined #instantbird 17:50:45 --> arlolra has joined #instantbird 18:00:59 <-- MikkCZ has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 18:10:19 <-- Mnyromyr has quit (Ping timeout: 121 seconds) 18:10:41 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 18:11:30 --> Mnyromyr has joined #instantbird 18:24:51 <-- Mnyromyr has quit (Ping timeout: 121 seconds) 18:25:53 --> Mnyromyr has joined #instantbird 18:40:13 --> myk has joined #instantbird 19:13:11 <-- myk has quit (Ping timeout: 121 seconds) 19:15:21 --> myk has joined #instantbird 19:19:30 <clokep_work> aleth: http://mxr.mozilla.org/comm-central/source/chat/protocols/irc/ircBase.jsm#197 19:19:41 <clokep_work> Looks like we find ourself in the JOIN list. 19:35:02 --> mpmc has joined #instantbird 19:47:44 --> EionRobb has joined #instantbird 20:26:42 --> flo-retina has joined #instantbird 20:26:43 * ChanServ sets mode +qo flo-retina flo-retina 21:08:28 --> satdav has joined #instantbird 21:09:10 <instantbot> aleth@instantbird.org changed the Resolution on bug 1089809 from --- to FIXED. 21:09:11 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1089809 nor, --, Instantbird 45, aleth, RESO FIXED, Unhandled IRC message 379 21:09:20 <instantbot> aleth@instantbird.org changed the Resolution on bug 1225454 from --- to FIXED. 21:09:21 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1225454 tri, --, Instantbird 45, martin, RESO FIXED, Unregistering IRC handlers doesn't work 21:11:22 <clokep_work> aleth: Thanks! 21:18:23 <-- myk has quit (Ping timeout: 121 seconds) 22:20:24 <freaktechnik> is there a way to make the user highlighting case-insensitive? As in, the colored usernames in instantbird. 22:20:34 <freaktechnik> (in messages) 22:22:01 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:24:46 <-- Tobin has left #instantbird ("Our job is to state the truth and let the facts attend to themselves.") 22:33:25 --> myk has joined #instantbird 22:34:28 --> abdelrhman has joined #instantbird 22:39:03 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 22:43:21 <-- abdelrhman has quit (Ping timeout: 121 seconds) 22:45:56 --> abdelrhman has joined #instantbird 22:46:39 <aleth> freaktechnik: if you override/modify the regex in conversation.xml 22:47:17 <abdelrhman> sukhe: Hi :-) 22:47:23 <-- Mnyromyr has quit (Connection closed) 22:50:27 <freaktechnik> aleth: so not really. Okay. 22:56:03 <aleth> it's probably not case insensitive to avoid false positives from short nicks 22:56:56 <aleth> freaktechnik: you could normalize the capitalization in the prpl though if you were confident of it 22:57:18 <aleth> i.e. display a version of the message with the correct capitalization 22:57:57 <EionRobb> do you not have a normalization function for usernames like the one in libpurple? 22:58:00 <freaktechnik> I couldn't figure out a way to have normalized buddies with capitalization in the displayed nicknames. 22:58:39 <aleth> EionRobb: sure, this is kind of the inverse problem though 22:58:55 <freaktechnik> so I currently have a messy getParticipant method, which replaces the normalized irc version of the nickname if I get proper capitalization 22:59:18 <EionRobb> oic, passing one username for the theme and one for display 22:59:58 <freaktechnik> well, no, I actually want the highlights to be totally insensitive, but having normalized nicks in the backend vs. display names would be nice, too. 23:00:05 <aleth> freaktechnik: the irc prpl stores known capitalizations in the whoisInfo 23:00:12 <freaktechnik> but that's a different problem... 23:00:25 <freaktechnik> aleth: oh? 23:00:49 <aleth> and the nicks in the participant list use the capitalization from the server 23:01:18 <freaktechnik> yeah, problem is that the server doesn't use the correct capitalization but instead has the correct capitalization in an IRC tag. 23:01:42 <aleth> lol 23:01:53 <freaktechnik> yeah, it's fun 23:02:57 <aleth> if you can get the tag at the point where the participant object is created, that should make it work 23:03:12 <freaktechnik> but the proprietary version of the chat ignores capitalization for highlights, so that's why I want to do that too 23:03:48 <freaktechnik> aleth: I have capitalization working in the UI, there are a few other quirks, like only PRIVMSGs having the tag but not JOINs etc. 23:04:20 <aleth> yeah, so the only way I can see to do that would be to display fReaKTECHNik occurrences in messages as freaktechnic ;) 23:04:44 <aleth> (so the conversation.xml regex picks it up) 23:04:48 <freaktechnik> you mean normalizing highlights myself? 23:04:51 <freaktechnik> interesting idea. 23:04:51 <aleth> right 23:05:05 <aleth> using the displayMessage mechanism 23:05:20 <freaktechnik> another regexp in there can't hurt 23:05:24 <-- satdav has quit (Quit: Leaving) 23:05:49 <aleth> you'd have to be careful about false positives 23:05:53 <EionRobb> oh, "highlights" as in a message arrived for oneself and it's displayed differently? 23:06:30 <freaktechnik> EionRobb: instantbird uses a color hashing on usernames and then colors all occurences of the username in that color 23:06:57 <EionRobb> ok yeah, that's what I thought you were talking about originially 23:07:13 <sukhe> abdelrhman: hi. I was here but now I am about to step out, sorry. can we talk later? sorry 23:08:45 <abdelrhman> OK, no problem 23:09:23 <sukhe> abdelrhman: please ping me the next time you come online. if it helps, I am in UTC -5 23:09:51 <abdelrhman> OK 23:10:26 <freaktechnik> aleth: the pattern for replacement would be along the lines of /(?:^|\s)username(?=\s|$)/gi which should give no false-positives. 23:11:04 <freaktechnik> I'd actually have to remember that first () to readd it when replacing. 23:11:06 <EionRobb> assuming the protocol has case-insenstive normalising of usernames 23:11:43 <freaktechnik> EionRobb: I'd replace that with the case-sensitive version of the username, so the highlight gets shown, yup 23:12:54 <-- myk has quit (Ping timeout: 121 seconds) 23:14:25 <freaktechnik> hm, though I'm not sure I'd want to do this on a room with over 100 people... 23:27:15 <abdelrhman> aleth: Is there another protocol that supports in-band registration? as I think we can make registration dialog generic. 23:29:05 <aleth> abdelrhman: not at the moment, though one could consider adding it (e.g. for IRC - register with nickserv) 23:29:22 <aleth> the problem to consider is what happens if the registration fails 23:29:24 <EionRobb> mxit 23:34:27 --> EionRobb1 has joined #instantbird 23:35:47 <abdelrhman> I think these kind of problems should be covered in XEPs 23:36:48 <-- EionRobb has quit (Ping timeout: 121 seconds) 23:37:34 <aleth> I'm sure they are. But how do you handle it in the UI? 23:37:41 <aleth> Something to think about ;) 23:43:29 <abdelrhman> Yeah, I got what you mean :) 23:53:29 --> clokep has joined #instantbird 23:53:29 * ChanServ sets mode +o clokep 23:54:13 --> myk has joined #instantbird 23:57:58 <-- pWnnn has quit (Ping timeout: 121 seconds)