All times are UTC.
00:07:57 <-- aleth has quit (Quit: Instantbird -- http://www.instantbird.com) 00:12:32 <-- myk has quit (Input/output error) 00:33:53 <-- clokep has quit (Input/output error) 00:33:57 --> clokep has joined #instantbird 00:33:57 * ChanServ sets mode +o clokep 00:40:40 <-- EionRobb has quit (Quit: Leaving.) 00:41:19 --> EionRobb has joined #instantbird 00:42:43 <clokep> Mic I fixed my LJ Talk protocol, but it's not really worth uploading it until we have the 1.2 flag on AIO. 00:56:45 <-- mmkmou has quit (Quit: Instantbird -- http://www.instantbird.com) 01:26:55 <instant-buildbot> build #216 of macosx-onCommit is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-onCommit/builds/216 01:40:00 <-- EionRobb has quit (Connection reset by peer) 01:40:18 --> EionRobb has joined #instantbird 01:44:50 <instantbot> wnayes@gmail.com requested review from clokep@gmail.com for attachment 1428 on bug 1391. 01:44:52 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1391 enh, --, ---, wnayes, ASSI, Simplify account creation wizard 01:46:43 --> wnayes has joined #instantbird 02:03:07 <clokep> wnayes: I don't think Florian is the initial dev of that file you added. ;) 02:05:29 <wnayes> clokep: all the GPL listings had seemed to be the same (at least with what I was working with) so I left it as is 02:05:47 <clokep> Yeah, it should be you. But don't change it now. 02:05:51 <clokep> There will be review comments. 02:06:33 <clokep> Later though. 02:13:31 <-- wnayes has quit (Quit: Instantbird -- http://www.instantbird.com) 02:15:48 <instant-buildbot> build #574 of win32-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/574 02:19:52 <-- EionRobb has quit (Ping timeout) 02:20:45 --> EionRobb has joined #instantbird 02:29:38 <-- clokep has quit (Quit: Instantbird -- http://www.instantbird.com) 02:31:55 <-- EionRobb has quit (Ping timeout) 02:32:03 --> EionRobb has joined #instantbird 02:33:45 <-- EionRobb has quit (Ping timeout) 02:34:29 --> EionRobb has joined #instantbird 02:34:50 <-- EionRobb has quit (Quit: Leaving.) 03:30:03 <instant-buildbot> build #484 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/484 03:31:08 --> EionRobb has joined #instantbird 03:36:17 <-- EionRobb has quit (Ping timeout) 04:20:25 <instant-buildbot> build #237 of win32-onCommit is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/win32-onCommit/builds/237 04:30:21 --> EionRobb has joined #instantbird 04:30:36 <-- Gizmokid2005 has quit (Ping timeout) 04:31:04 <-- harisund has quit (Ping timeout) 04:31:04 <-- jwir3|away has quit (Ping timeout) 04:34:23 --> Gizmokid2005 has joined #instantbird 04:35:22 --> jwir3 has joined #instantbird 04:35:23 <-- EionRobb has quit (Ping timeout) 04:39:17 --> harisund has joined #instantbird 04:44:49 --> micahg has joined #instantbird 04:54:57 --> EionRobb has joined #instantbird 04:57:29 <-- EionRobb has quit (Ping timeout) 05:02:16 --> EionRobb has joined #instantbird 05:06:06 <-- micahg has quit (Ping timeout) 05:07:38 --> micahg has joined #instantbird 05:12:39 <-- harisund has quit (Ping timeout) 05:12:41 --> harisund has joined #instantbird 05:18:56 <-- EionRobb has quit (Ping timeout) 05:26:11 <-- skeledre1 has quit (Ping timeout) 05:50:47 <-- Suiseiseki has quit (Ping timeout) 05:51:28 --> Suiseiseki has joined #instantbird 05:53:54 --> Mic has joined #instantbird 05:53:54 * ChanServ sets mode +h Mic 05:54:48 <Mic> Hello. 06:04:13 <instant-buildbot> build #471 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/471 06:07:49 <-- gpsychosis has quit (Ping timeout) 06:07:50 --> gpsychosis has joined #instantbird 06:34:06 --> EionRobb has joined #instantbird 06:37:04 <-- DGMurdockIII has quit (Connection reset by peer) 06:37:13 --> DGMurdockIII has joined #instantbird 06:41:07 <-- Kaishi has quit (Quit: Kaishi) 06:41:09 <-- gpsychosis has quit (Connection reset by peer) 06:42:29 --> gpsychosis has joined #instantbird 06:42:50 <-- Suiseiseki has quit (Ping timeout) 06:47:26 --> Suiseiseki has joined #instantbird 06:56:50 --> gerard-majax has joined #instantbird 07:00:15 <-- DGMurdockIII has quit (Ping timeout) 07:04:05 --> jb has joined #instantbird 07:05:41 --> DGMurdockIII has joined #instantbird 07:17:04 <-- jb has quit (Ping timeout) 07:46:30 --> aleth has joined #instantbird 07:46:30 * ChanServ sets mode +h aleth 07:48:49 --> Even1 has joined #instantbird 07:48:54 <-- Even1 has quit (Quit: Even1) 07:49:12 --> Even1 has joined #instantbird 07:49:45 <-- EionRobb has quit (Quit: Leaving.) 07:50:45 <-- aleth has quit (Quit: Instantbird -- http://www.instantbird.com) 07:50:56 --> aleth has joined #instantbird 07:50:56 * ChanServ sets mode +h aleth 07:59:55 <-- Mook_as has quit (Ping timeout) 08:00:32 --> je has joined #instantbird 08:04:43 --> Mook_as has joined #instantbird 08:11:08 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 08:16:49 --> Mic has joined #instantbird 08:16:49 * ChanServ sets mode +h Mic 08:18:18 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 08:18:59 --> Mic has joined #instantbird 08:18:59 * ChanServ sets mode +h Mic 08:19:05 <-- Mic has quit (Connection reset by peer) 08:19:56 --> Mic has joined #instantbird 08:19:56 * ChanServ sets mode +h Mic 08:24:46 --> mmkmou has joined #instantbird 08:29:17 <-- je has quit (Quit: je) 09:01:49 <-- mmkmou has quit (Ping timeout) 09:05:09 --> mmkmou has joined #instantbird 09:08:13 --> EionRobb has joined #instantbird 09:15:06 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 09:16:33 --> flo has joined #instantbird 09:16:33 * ChanServ sets mode +qo flo flo 09:20:56 <instantbot> aletheia2@fastmail.fm denied review for attachment 1424 on bug 318. 09:21:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=318 enh, --, ---, clokep, ASSI, Check if topic on IRC channels is editable and make UI respond accordingly 09:23:55 --> Mic has joined #instantbird 09:23:55 * ChanServ sets mode +h Mic 09:24:50 <Mic> Yay, context messages from logs. Fetched by the logger and conversation object. No change to conversation.xml anymore :) 09:28:10 <flo> :) 09:28:38 <aleth> Nice :) 09:29:53 <-- micahg has quit (Quit: Ex-Chat) 09:30:15 <flo> wnayes' new patch looks like this: http://i.imgur.com/LS30W.png 09:31:50 <Mic> Looks good except for the scrollbar. 09:32:11 <Mic> He's doing pretty well from what I've seen. Does he have experience with the Mozilla platform already? 09:32:13 <flo> I don't understand how that "Show all available protocols" checkbox is an improvement 09:33:27 <flo> and toggling the value of that checkbox causes some flickering, which the previous version didn't cause 09:34:49 <flo> what's displayed at https://add-ons.instantbird.org/en-US/instantbird/1.2a1pre/protocols/ for you? I see a forbidden error :-S (not related to wnayes' patch at all) 09:35:19 <Mic> The overview page, only listing LJ Talk in every column at the moment. 09:35:38 <flo> ok, I probably have some wrong IP in my hosts file then 09:36:44 <flo> yes, that was the problem :) 09:38:17 <aleth> Looks like wnayes is finding his way around quickly :) 09:38:49 <flo> yes :) 09:38:58 <aleth> I don't really like the checkbox version better either though :-/ 09:39:26 <flo> the confusing feedback we sent yesterday that caused a less pleasant to use version to be created isn't as great as his progress :-/ 09:39:48 <aleth> Yeah :-/ 09:39:50 <flo> aleth: I find it quite difficult to use 09:40:18 <flo> aleth: you have to first scroll the list to see what's there, then be annoyed by the lack of what you were looking for, then look around and notice the checkbox, that most people may not see at all 09:40:22 <aleth> But that's what happens with any bug that changes the UI 09:40:57 <aleth> Yes, it's more complicated. 09:41:24 <aleth> Most importantly, it looks more complicated. 09:42:06 <aleth> What did you think of my suggestion to simply resize the window so there is no scrollbar (should be possible on most screens)? 09:43:13 <flo> aleth: it's not a good idea 09:43:51 <flo> wizards usually have the same standard size for all applications 09:44:32 <aleth> It's very small though. 09:44:33 <flo> (except maybe on linux where applications are based on various different toolkits and may not respect any UI conventions (and this is almost too easy for Mic to add some comment about linux looking bad in general :-D)) 09:45:06 <aleth> In many ways he would be right ;) 09:46:50 --> jb has joined #instantbird 09:48:32 <aleth> Though it's nothing compared to what might happen when the web becomes the platform ;) 09:52:47 <Mic> Does it need to be a listbox on this page? If the user is seeing all options at once (and I think she should) we could as well use buttons and save the user a click on the next-button? 09:53:59 <flo> larger-than-normal buttons tend to look very ugly on mac 09:54:32 <Mic> Sorry, I meant buttons function-wise, not necessarily looking like native buttons. 09:58:21 <aleth> A listbox without a scrollbar would act like that already, as long as you double-clicked? 09:59:28 <aleth> Some space could be saved by ditching the text above the listbox and putting that information in the title (curerntly useless) 10:00:10 <aleth> Would that be enough to show all items including "Show all"? 10:00:19 <flo> I think the title and line of blahblah look completely different on Windows 10:00:33 <flo> aleth: what about you forget that idea of not having a scrollbar? :) 10:02:04 <flo> aleth: while I agree that scrollbars suck (in general), I think getting rid of this one is not the goal for this bug. What we are trying to get rid of is confusing protocol names being shown to the user during the first contact with the application. 10:06:46 <aleth> Well, sure, it's already fixed that problem of course. But like with any new feature you want to get the UI right. And it just seems hard to see why there is no good way the small number of 5 options can't be shown at once... 10:07:00 <Mic> Poor mockup, bottom right would be reserved for "Show others - my network isn't listed here". Background would be a fancy Leibovic-gradient based on the icon. 10:07:02 <Mic> http://imgur.com/In5xv 10:07:30 --> sonny has joined #instantbird 10:08:36 <aleth> That could work :) In particular you could have those 4 be protocols and 'Show others' or whatever a slightly different shape underneath 10:08:47 <flo> Mic: I dislike splitting the list in two columns 10:09:55 <flo> aleth: "And it just seems hard to see why there is no good way the small number of 5 options can't be shown at once..." we haven't decided there are 5 options. Adding back AIM and Yahoo! seems very likely for en-US. 10:10:00 <Mic> It's not a list anymore, don't you see? ;) 10:10:36 <aleth> flo: Oh, I thought the number of popular items was fixed. 10:10:42 <flo> Mic: I see that I couldn't let my father select anything in that screen without having to first get in front of the computer, grab the mouse, and click the button myself 10:20:31 --> clokep has joined #instantbird 10:20:31 * ChanServ sets mode +o clokep 10:25:00 <clokep> I agree with flo that it needs to be a listbox since the number of popular items is *NOT* fixed. 10:25:08 <clokep> Different locales will have different numbers. 10:25:34 <aleth> Yeah, I didn't realize that, which makes most of my comments useless 10:31:53 <clokep> We should probably give some more directed feedback in the bug though. :) 10:32:59 <flo> clokep: you mean something like "do this, this and this"? ;) 10:33:31 <Mic> Ah, when the number is not fixed things are different, that's true. 10:34:41 <aleth> I wonder if (going back to the first design) the "Show all" entry should be given a different background colour to distinguish it 10:35:00 <clokep> aleth: I was thinking a separated between it and the other items. 10:35:03 <aleth> Or a separator above it... 10:35:12 <flo> aleth: possibly. Or a light grey dotted top border 10:35:19 <aleth> Yes 10:35:28 <aleth> Something like that. 10:35:45 <clokep> flo: I just don't like giving confusing feedback. :( 10:36:16 <flo> clokep: yeah, I was quite disappointed by the result caused by our confusing feedback sent yesterday :( 10:36:38 <flo> clokep: it seems we are going to cause wnayes some unneeded frustration... 10:36:45 <aleth> Feedback on any UI bug has a tendency to be 'confusing' in my experience, simply because you can't judge the suggestions properly until they are implemented 10:36:46 <clokep> Exactly. 10:36:52 <flo> clokep: although I think I would also be interested to know what he thinks about it! 10:37:27 <clokep> Yes. :) Instead of just implementing our suggestions. 10:38:03 <aleth> Yes :) Especially as after all he is a recent new user of Instantbird ;) 10:38:26 <flo> aleth: I don't think I agree. The confusion yesterday came from lots of people saying different things, without meaning that they should actually be implemented now (it was just ideas); and it wasn't clear who said things that needed to be implemented, and who was just brainstorming out loud 10:38:50 <aleth> I thought it was clear it was just brainstorming? None of it was a review in the bug... 10:39:49 <flo> aleth: I wonder which one of comment 6 and comment 8 wasn't in the bug. :-P 10:41:08 <aleth> That wasn't yesterday :P and was formulated very tentatively on purpose 10:41:10 <clokep> aleth: We do have our reviews on IRC though. 10:41:16 <clokep> s/have/half/ 10:41:51 <aleth> What I meant was nobody was saying "wnayes should do this" 10:42:15 <aleth> But of course he might have thought it implicit 10:42:46 * flo thinks the feedback received in https://bugzilla.mozilla.org/show_bug.cgi?id=743235 is confusing :( 10:43:18 <aleth> I don't see it as all bad, a lot of ideas being thrown around means the actual coder can read and make up his own mind... 10:44:13 <-- EionRobb has quit (Quit: Leaving.) 10:44:15 <flo> I did; and think gloda sucks :-P. 10:44:44 <aleth> Oh, I was still referring to yesterday's convo, not the gloda bug ;) 10:45:59 <clokep> aleth: Yes I agree, he needs to understand how we work too. :) 10:46:19 <clokep> flo: That bug confused me 5 or 6 emails ago, if not before that. :( 10:46:40 <clokep> flo: Does deleting a contact over JS-XMPP work? 10:48:23 <flo> aleth: I intentionally changed the topic because I was going to get upset at someone (most likely you) for bad reasons (mostly that I have a headache since yesterday evening that makes me slightly more irritable, that there has been a baby in the office for the last 2 hours making distracting noises, and that I'm generally frustrated when I attempt to touch gloda code :-P) 10:49:05 <flo> clokep: it should: http://lxr.instantbird.org/instantbird/source/chat/protocols/xmpp/xmpp.jsm#367 10:52:59 <clokep> Hmm. OK. 11:00:26 * flo rereads these comments for the third or forth time to see if he has forgotten anything 11:05:12 <-- clokep has quit (Ping timeout) 11:26:01 <-- jb has quit (Ping timeout) 11:30:55 --> EionRobb has joined #instantbird 11:36:07 <-- Mic has left #instantbird () 11:36:13 --> Mic has joined #instantbird 11:36:13 * ChanServ sets mode +h Mic 11:40:44 <Mic> flo: we don't change uuids when interfaces change, do we? 11:42:37 <-- EionRobb has quit (Quit: Leaving.) 11:47:27 <Mic> bye 11:47:31 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 11:52:18 --> clokep_work has joined #instantbird 11:52:18 * ChanServ sets mode +o clokep_work 11:55:40 <clokep_work> Mic: NO, we don't. But if that's messing you up somewhere we can. 12:04:27 --> jb has joined #instantbird 12:12:45 <flo> Mic: we don't until someone gives me a convincing reason explaining why we should :) 12:13:13 <aleth> clokep_work: I'm a bit puzzled why your last patch didn't work. I couldn't see any obvious problem in the code... 12:18:20 <clokep_work> aleth: I tested it, although not as much as I had tested it previously. But maybe I did something crazy and didn't actually rebuild before testing it at one point or something. 12:18:38 <clokep_work> Also, please refrain from issues w/ the /mode command not giving proper responses, it's not part of that bug. 12:19:01 <clokep_work> Feel free to file other bugs on them though. 12:19:24 <aleth> I said it wasn't in my comments... I just left them there because I wasn't sure I had overlooked a bug that had already been filed on those. 12:22:00 <clokep_work> It makes it difficult for me to follow what's related to that bug though. Bugs are cheap, just file 'em if it's a dup we'll dup it. :) 12:22:14 <aleth> OK. 12:22:43 <clokep_work> Thanks! :) 12:22:50 <clokep_work> I'll look at it again tonight though. 12:22:58 <clokep_work> Hopefully it's just something trivial I messed up. 12:23:11 <clokep_work> I thought this patch was a lot nicer though that I combined the notification into the setMode method. :) 12:23:23 <aleth> Yes, it's a great patch :) 12:26:57 --> skeledre1 has joined #instantbird 12:29:00 <clokep_work> I still dislike the # of places we seem to have to fire the update-topic notification though. :( But I think there's just so many different ways it can occur... 12:29:22 <aleth> Yeah :-/ 12:34:01 <-- jb has quit (Ping timeout) 12:37:15 * clokep_work is going to leave feedback on bug 1391... 12:37:19 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1391 enh, --, ---, wnayes, ASSI, Simplify account creation wizard 12:37:22 <flo> :) 12:42:07 <instantbot> New Core - IRC bug 1419 filed by aletheia2@fastmail.fm. 12:42:10 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1419 nor, --, ---, nobody, NEW, Add the remaining missing /mode responses 12:43:32 <clokep_work> Thanks aleth. 12:44:11 <clokep_work> Hmmm...creation time...is that sent with a channel name aleth? 12:44:19 <clokep_work> (I'm guessing it's when the channel was created, if so...) 12:44:43 <aleth> I'll add an example 12:45:30 <clokep_work> Feel free to just copy & paste the entire error console output thing btw, it should have the raw message if not the JSONified message (both is handy btw). 12:45:39 <clokep_work> Although the JSON one includes the raw message... 12:47:28 <clokep_work> Hanging out on gravel, I see. Not on concrete? ;) 12:48:02 <aleth> I don't know why... isn't that automatic? ;) 12:48:15 <flo> isn't gravel the one for european IPs? 12:49:33 <clokep_work> Yeah, it's in Europe somewhere. 12:49:42 <clokep_work> It is automatic if you hit irc.mozilla.org, yes. :) 12:49:45 <flo> near Amsterdam I think 12:55:35 <aleth> GAH 12:55:47 <aleth> clokep_work: Ignore the review on bug 318 for now 12:55:50 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=318 enh, --, ---, clokep, ASSI, Check if topic on IRC channels is editable and make UI respond accordingly 12:56:35 <aleth> It seems the update to the latest nightly was messed up on my dev install 12:56:52 <aleth> That could be causing all the problems for which I can't find a reason in the code ;) 12:57:12 <aleth> Sorry about that :( 12:58:43 <clokep_work> It's OK. :) It happens. 12:58:46 <aleth> Yes, that fixed it. 12:58:57 <aleth> What a waste of time and confusion... 13:00:15 <clokep_work> Well, hopefully it all Just Works now! :-D 13:00:33 <clokep_work> I think it might still be r- though. :-/ I want to read over it again before it gets checked-in... 13:01:45 <aleth> It behaves the way I would expect it to from the code now :D that's a big plus ;) 13:05:16 <clokep_work> Ah-ha! :) 13:05:43 <clokep_work> (Things that shold probably be changed: I realized when we call the setMode function of a participant...that should probably have the observer notification in that function) 13:07:44 <flo> hmm, I changed something in some gloda code, and now nothing works any more, and not a single warning or error message :-S 13:08:34 --> jb has joined #instantbird 13:09:59 --> jb1 has joined #instantbird 13:10:28 <clokep_work> flo: It does make me wonder if you could have rewritten gloda in the time you've spent integrating into it. ;) 13:12:40 <flo> I've wondered that several times. But I suspect it already handles/works around lots of tricky edge cases that I would have had to deal with too 13:15:26 <instantbot> New Core - IRC bug 1420 filed by aletheia2@fastmail.fm. 13:15:29 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1420 nor, --, ---, nobody, NEW, Add discoverable explanations for the possible modes 13:15:41 <flo> + removing APIs exposed to add-on authors isn't really great 13:18:15 <-- jb has quit (Ping timeout) 13:18:26 <-- jb1 has quit (Ping timeout) 13:22:01 * flo wonders why bug 1419 has received "[1.2-wanted]". Is it a regression? 13:22:05 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1419 nor, --, ---, nobody, NEW, Add the remaining missing /mode responses 13:23:58 <aleth> The 1.2-wanted doesn't apply to all of it imho, but it does apply to the first item mentioned in the bug, which might be a regression (I don't know) but is certainly not good. 13:26:17 <flo> I don't think it should be set without an explanation of why it's there 13:29:28 <clokep_work> aleth: You ask for hard things with IRC. ;) 13:29:37 <clokep_work> They're things I want too, they're just difficult. :-/ 13:30:07 <aleth> Yes, unfortunately :( 13:30:45 <aleth> If you disagree with the 1.2-wanted, feel free to remove it. I haven't got a 1.1 installed to check if it's a actually a regression. 13:32:10 <flo> aleth: I disagree with it being set without any discussion or reason, because we won't really know why it's here when cleaning up that list later. And I don't understand that bug, so I don't really have an opinion for how needed that feature is 13:33:06 --> pvagner has joined #instantbird 13:33:07 <flo> that doesn't mean the bug shouldn't be fixed of course :) 13:34:03 --> NmN has joined #instantbird 13:37:34 <-- pvagner has quit (Ping timeout) 13:42:56 * bear-afk is now known as bear 13:42:57 * clokep_work replied to wnayes. 13:48:35 <clokep_work> aleth: Does the 482 reply not insert the channel name properly? :( 13:49:45 <aleth> clokep_work: "03:29:23 PM - You are not a channel operator on $S." 13:50:17 * clokep_work grumbles. 13:50:30 <clokep_work> Should be a %, not a $. Good find. 14:03:03 --> Guido has joined #instantbird 14:34:35 * bear is now known as bear-afk 14:44:43 <aleth> Modes not being standard across servers, I guess I shouldn't be surprised... 14:44:58 --> pvagner has joined #instantbird 14:47:35 <-- gerard-majax has quit (Ping timeout) 14:49:53 * bear-afk is now known as bear 14:51:57 <clokep_work> I think I'd be more surprised if they weren't. ;) 14:52:08 <clokep_work> It's still doable though, just more complicated. 14:58:49 <-- meh has quit (Ping timeout) 15:19:51 --> BYK has joined #instantbird 15:37:15 <-- flo has quit (Ping timeout) 15:47:23 --> flo has joined #instantbird 15:47:23 * ChanServ sets mode +qo flo flo 15:49:27 <-- pvagner has quit (Ping timeout) 15:57:56 --> micahg has joined #instantbird 16:03:20 --> meh has joined #instantbird 16:06:43 --> igorko has joined #instantbird 16:07:27 --> myk has joined #instantbird 16:10:27 --> wnayes has joined #instantbird 16:12:34 * bear is now known as bear-afk 16:24:14 <-- NmN has quit (Quit: Instantbird 1.1) 16:27:03 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120425123149]) 16:27:55 <clokep_work> wnayes: Sorry about any confusion from yesterday. :( 16:28:59 <-- skeledre1 has quit (Ping timeout) 16:29:56 <aleth> wnayes: Ditto from me... 16:30:18 <wnayes> Well, I'm learning a lot from the experience either way :) 16:31:49 <wnayes> Although I felt that the second patch was overall a stronger proposal than the first... 16:31:55 <clokep_work> What'd you think of that design instead of the other option anyway? I'd really like it to be more of a discussion than us telling you what to do! 16:33:16 <wnayes> I did not experience any flickering issues, and I reasoned that a static element on the page would provide a more reliable way to reach the longer list 16:34:23 <clokep_work> I think by "flickering" aleth and flo just meant the content of the tab changing...but only kind of changing. I personally thought it looked OK too, but the checkbox did seem a little hidden. 16:34:23 <wnayes> The confusion of the wizardpage back/next behavior was removed as well 16:34:36 <clokep_work> Yes, that's true. :) 16:34:45 <aleth> I didn't see any flickering as I didn't test that second patch ;) 16:35:00 <wnayes> Perhaps on my end the checkbox appears larger? http://i.imgur.com/SSCZr.png 16:35:46 <aleth> If one were to go with that option, the "Get more..." would have to be hidden until the checkbox was ticked. 16:35:49 <flo> clokep_work: it actually flickers, because the icons of list items don't appear immediately 16:36:08 <aleth> Otherwise it is potentially confusing. 16:36:23 <-- flo has quit (Quit: Instantbird -- http://www.instantbird.com) 16:36:28 <clokep_work> flo: Oh, really? I didn't see that. 16:36:45 <clokep_work> wnayes: Yes on Windows 7 the text/checkbox is all a bit smaller I think. I should have made a screenshot. :( 16:37:40 <aleth> It's not an easy problem to find a good design as you have short list -> long list -> potentially "get more" 16:40:46 * clokep_work thinks UI leads to too much bikeshedding... 16:41:37 <aleth> It's very satisfying when it's finally "right" though :) 16:42:08 <clokep_work> I think the "test" for it is to give it to people who aren't very computer savvy and see which one is easier hah. 16:42:31 <clokep_work> I think the checkbox is more elegant in a lot of ways, but potentially more confusing as it's nonlinear. 16:47:14 --> DGMurdockIII has joined #instantbird 16:47:27 * aleth discovers bug 1415 is trickier than he expected 16:47:31 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1415 nor, --, ---, aletheia2, ASSI, Unread ruler should also appear after last context message 16:48:55 <clokep_work> wnayes: So I asked one of my friends, she said: "[for http://i.imgur.com/7h5td.png] when you're looking at the list, the "other" choice is right where you're looking you have to search a little more to click the box". 16:49:07 <clokep_work> Which I think is what flo was concerned about as well. 16:49:39 <DGMurdockIII> that look nice 16:49:41 <DGMurdockIII> man 16:50:58 <clokep_work> aleth: I'm sure you'll be able to figure it out. :P 16:51:15 <aleth> What if one tried that design, with a separator (maybe a subtle one - a dashed top border was suggested) before the "Show all" option (or maybe a shaded background), and on double-clicking "Show All" went directly to the long list (or single click + Next of course) 16:51:45 <clokep_work> That pretty much is the other design, minus the word changes + the border. 16:51:48 <wnayes> clokep_work: I would agree in that case, but when http://i.imgur.com/r1M6c.png situation arises it is less of a clear choice 16:52:27 <clokep_work> wnayes: But at first you're going to look through the list to see if the network you want is there anyway, you scroll and voila at the end there's an other option! 16:52:53 <clokep_work> I don't think scrolling is an issue personally. If we're incredibly concerned...we could probably reduce the size of the items a bit. 16:54:58 <wnayes> The scrolling becomes an issue when adding additional accounts and finding that the only way to get to them is scrolling past the top list each time to advance. 16:55:20 <aleth> clokep_work: Since the number of top protocols is not determined, one probably can't guarantee they'll all fit anyway, so reducing the size doesn't really help 16:56:00 <clokep_work> aleth: I agree. 16:56:11 <clokep_work> wnayes: Ah, OK. So that's the problem. Not that it's hidden. Good. 16:56:19 * clokep_work wants to think now. ;) 16:56:48 <aleth> wnayes: A different approach could be something like "if the user has selected a protocol from the full list at least once, set a pref and never show her the shortened list again"? 16:56:53 <aleth> (just thinking aloud) 16:57:26 <clokep_work> That gets confusing for the user ("Why is there a different UI all of a sudden?!") 16:58:00 <wnayes> As someone who uses a variety of accounts personally, I could see that extra step of needing to scroll through the list mundane, say, when needing to add a handful of irc accounts (assuming IRC is not a top list contender :) ) 16:59:21 <clokep_work> Yes, IRC won't be in the top list. 16:59:27 <clokep_work> wnayes: I agree with what you're saying. 16:59:28 <aleth> clokep_work: Is it really confusing if you only do it after an account from the long list not in the short list has actually been added? At that point the user knows the full list anyway 16:59:34 <clokep_work> It's hard to make UI that's good for beginners and experts. :( 16:59:52 <clokep_work> aleth: Ah I read that backwards! Yes...that might not be too bad. 17:00:07 <aleth> wnayes: I agree. (But I think flo was of the opinion nobody sets up accounts that often...) 17:01:49 * clokep_work wonders if maybe a "Set up another account" on the last page of the wizard, which brings you back to the page you selected from would fix that...? 17:02:48 <aleth> clokep_work: Hmm... I'm not sure many people are that efficient. Usually you'd want to test a newly added account first. 17:03:22 <aleth> But I don't really know what most people would do ;) 17:03:45 <clokep_work> That mythical "normal user", right? ;) 17:04:37 <aleth> I think what you said about trying to get it right for both beginners and experts is a good approach (though difficult). 17:04:44 --> jb has joined #instantbird 17:04:52 <clokep_work> It's how we think about most of our UI honestly. 17:05:00 <clokep_work> Although I'm really not very good at UI. :-S 17:05:06 <aleth> Thankfully :) 17:05:20 <-- jb has quit (Input/output error) 17:05:26 <aleth> (referring to the first not the second message ;) ) 17:05:33 --> jb has joined #instantbird 17:06:26 <clokep_work> I'm sure. :P 17:06:27 <aleth> Btw please test the section scroll behaviour! :) 17:06:51 <clokep_work> Will do at some point. 17:07:06 <-- jb has quit (Input/output error) 17:07:09 --> jb has joined #instantbird 17:08:18 --> flo has joined #instantbird 17:08:18 * ChanServ sets mode +qo flo flo 17:09:02 <flo> sorry for disappearing... everybody has been moving desks around in the office this afternoon, and the time to move mine came unexpectedly ;) 17:09:24 --> Kaishi has joined #instantbird 17:09:39 <clokep_work> It's OK! You have some stuff to catch up on. :p 17:10:16 <-- Kaishi has quit (Quit: Kaishi) 17:10:20 --> Kaishi has joined #instantbird 17:11:52 * clokep_work goes to get a sub. 17:12:48 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120425123149]) 17:17:41 <flo> wnayes: the real problem I see with http://i.imgur.com/r1M6c.png is that without an item at the end of the list being partially visible, it's possible to not notice the scrollbar 17:18:17 <flo> I understand your concern about that step (and especially having to scroll) being annoying for expert users. 17:18:50 <flo> what about making the "continue" button go to the full list if nothing is selected in the short list? Would that help? 17:18:59 <flo> expert users would just press enter to skip that step 17:19:42 <flo> I have to setup accounts very often my self. I typically press enter immediately after opening the wizard to skip the pointless "welcome" step, then I type the first few characters of the protocol I want, and press enter again 17:19:42 --> BYK1 has joined #instantbird 17:20:21 <aleth> I'm not sure even an expert user would discover that possibility, especially when the welcome screen is gone. I don't think I would. 17:20:25 <-- igorko has quit (Ping timeout) 17:20:37 <clokep_work> flo: Ah you reminded me! Typing a few characters doesn't work anymore. :( 17:20:40 <flo> (and by the way, I'm annoyed each time I try a new profile on linux, because pressing enter immediately after opening the wizard there closes the dialog, as for some reason "cancel" is focused by default on linux) 17:20:53 <-- BYK has quit (Ping timeout) 17:20:59 <clokep_work> "doesn't work anymore" (with that patch) 17:21:10 <clokep_work> aleth: You can actually select "Other" by default than. 17:21:11 <aleth> flo: Yes, that's also a bug :-/ 17:21:14 <flo> clokep_work: when restoring the old list box for the full list, it will work again, right? :) 17:21:51 <clokep_work> It should. 17:21:54 <aleth> flo: What did you think of my idea with the pref? 17:22:01 * clokep_work is /actually/ going to get a sub this time. 17:22:15 <flo> I think whether we want the first or second design, we will restore the old listbox, if only to avoid the flickering. (we can have both the richlistbox and the old listbox in a desk if we want to go with the checkbox approach) 17:22:46 <flo> aleth: I agreed with clokep_work's comment (I think it was him) saying that it seems nice, but would actually has the potential to be confusing. 17:24:49 <flo> clokep_work: "You can actually select "Other" by default than." I almost suggested that instead of suggesting to show the full list when nothing is selected, but I think if some locales pick only 2 or 3 protocols to show by default, having the last item of the list selected by default would look odd. 17:25:51 <aleth> flo: My thinking was, why would you want the short list back if you have needed the long list once already? 17:26:08 <aleth> (actually needed, not just looked at) 17:26:43 <flo> aleth: because your son as setup an account for you a year ago? 17:26:47 <flo> *has 17:27:05 <aleth> Right. 17:29:01 <flo> I've got to go. 17:29:03 <-- flo has quit (Quit: Instantbird -- http://www.instantbird.com) 17:33:38 --> igorko has joined #instantbird 17:37:17 <instantbot> aletheia2@fastmail.fm set the Resolution field on bug 1357 to FIXED. 17:37:20 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1357 nor, --, ---, aletheia2, RESO FIXED, Add unread ruler to section scroll 17:39:49 <instantbot> aletheia2@fastmail.fm requested review from florian@instantbird .org for attachment 1429 on bug 1415. 17:39:54 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1415 nor, --, ---, aletheia2, ASSI, Unread ruler should also appear after last context message 18:06:24 <-- Kaishi has quit (Quit: Kaishi) 18:15:15 --> DGMurdockIII has joined #instantbird 18:17:12 <-- wnayes has quit (Quit: Instantbird -- http://www.instantbird.com) 18:31:03 --> Mic has joined #instantbird 18:31:03 * ChanServ sets mode +h Mic 18:39:24 <instantbot> aletheia2@fastmail.fm cancelled review?(florian@instantbird .org) for attachment 1429 on bug 1415. 18:39:25 <instantbot> aletheia2@fastmail.fm requested review from florian@instantbird .org for attachment 1430 on bug 1415. 18:39:28 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1415 nor, --, ---, aletheia2, ASSI, Unread ruler should also appear after last context message 18:40:37 * bear-afk is now known as bear 18:43:24 <-- igorko has quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19:10:59 <-- wesj has quit (Connection reset by peer) 19:14:46 --> wesj has joined #instantbird 19:16:08 --> flo has joined #instantbird 19:16:08 * ChanServ sets mode +qo flo flo 19:29:09 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 19:30:04 <instantbot> New Core - XMPP bug 1421 filed by marc_smith@gmx.com. 19:30:07 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1421 blo, --, ---, nobody, UNCO, XMPP- endless reconnect loop with SSL synchronisation error 19:40:27 <-- BYK1 has quit (Ping timeout) 19:40:51 <instantbot> florian@instantbird.org set the Resolution field on bug 1421 to DUPLICATE of bug 1100. 19:40:55 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1421 maj, --, ---, nobody, RESO DUPLICATE, XMPP- endless reconnect loop with SSL synchronisation error 19:40:56 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1100 cri, --, ---, nobody, NEW, Use Firefox untrusted cert dialog for "SSL Handshake failed" errors 19:41:51 --> BYK1 has joined #instantbird 20:04:45 <flo> aleth: you still have the patch for bug 1415 in mind, right? can I ask some questions here instead of reading the code for a while? :) 20:04:48 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1415 nor, --, ---, aletheia2, ASSI, Unread ruler should also appear after last context message 20:04:58 <aleth> Sure! 20:05:12 <flo> do you know what |--this._readCount;| is for? 20:06:15 <aleth> _readCount is the number of context messages (already read messages) still to be displayed on opening the conversation. 20:07:02 <aleth> So it is decreased each time we display a context message. When it's zero after the -- we are just displaying the last context message on the current call. 20:08:08 <flo> ok! 20:08:12 <flo> can _readCount be < 0 ? 20:08:40 <aleth> It can be in my patch, that's the point of the change. 20:09:01 <aleth> It then counts (-) the number of (new) messages displayed in the conversation 20:09:41 <flo> uh, ok. I'll need to read that part again :) 20:10:03 <-- mmkmou has quit (Quit: Instantbird -- http://www.instantbird.com) 20:10:22 <aleth> I thought there would be a more minimal/elegant solution to this bug, but it turned out more special-casey than I thought. 20:10:35 <aleth> So I added some comments... 20:10:36 <flo> I don't understand "// Don't set any unread flags if we are just opening the conversation." why wouldn't you want to set the flags if there's only one new message (opening the conversation) but no context? 20:11:07 <aleth> Because if we are opening the conversation, the tab is focused and selected and so the flag will never get cleared. 20:11:26 <aleth> The standard behaviour is for the flag to go away when a tab is selected 20:12:28 <flo> the setUnreadFlag variable is based on a check for whether the tab is selected and the window focused 20:12:47 <flo> it's the check for !this._haveContextMessages that I don't understand 20:13:20 <aleth> the setUnreadFlag variable now also allows the case where we are opening the conversation 20:14:41 <aleth> Maybe it would be better to split up the various combined booleans differently now? I wasn't sure. 20:15:42 <aleth> (we are opening the conversation and adding context messages -> this._haveContextMessages is true) 20:29:41 <-- meh has quit (Quit: I don't want to live on this planet anymore.) 20:32:08 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120501201020]) 20:36:12 <aleth> Actually I just realized in the final version of my patch there is no reason for _readCount to go negative, so I could do without moving that line. 20:37:15 <flo> could it be the reason why I didn't understand that? :) 20:37:55 <aleth> It might be :) Though it makes no difference really. 20:39:22 <aleth> After you review it, I can change the comments if they aren't clear enough too. 20:39:53 <flo> if you are going to attach another patch soon, the nits I found are: you don't need to name the function used as the sort comparator, and I think you don't need to test if (this._haveContextMessages) before deleting it (deleting a non existent property doesn't cause a warning) 20:40:24 <aleth> I won't attach another patch until you are done to avoid confusion. 20:40:34 <flo> ok 20:41:01 <aleth> I knew there wouldn't be a delete warning, but I thought it was IB coding style to check... 20:41:20 <aleth> Good to know one can save those if's 20:42:00 <flo> ah? it's possible there are other similar tests, it's not something we strongly enforce either way :) 20:42:24 <aleth> I might have misinterpreted something a long time ago... 20:42:27 <aleth> If I don't name the function, how do I specify its parameters? 20:47:00 --> BYK2 has joined #instantbird 20:48:37 <-- BYK1 has quit (Ping timeout) 20:49:01 <flo> I think I don't understand why you need the _haveContextMessages value at all :-S 20:49:29 <flo> aleth: sort(function(a, b) a[0] - b[0]); should work 20:50:00 <aleth> OK, good to know 20:50:14 --> EionRobb has joined #instantbird 20:50:55 <aleth> _haveContextMessages tells addMsg the message is being added by showFirstMessages (and is in the context message part) 20:50:59 <flo> aleth: it seems your code sets the unread flags only for the first unread message, which is when this._readCount is == -1. Or is there something I missed? 20:52:43 --> Mic has joined #instantbird 20:52:43 * ChanServ sets mode +h Mic 20:53:43 <aleth> If you are looking at |if (setUnreadFlag && !this._haveContextMessages)...|, it sets them completely independently of the readCount value (well, it's <=0 from the position in the code, but is not checked), and only if the message being added is not being added from showFirstMessages. 20:53:56 <aleth> So that's not only for the first unread message. 20:54:30 <aleth> Otherwise you would never get pinged ;) 20:56:26 <aleth> Hmm, I think there may be a ping-related bug, but it's not the one you are thinking of I think. 20:57:39 <flo> the bug I'm thinking of is "it's impossible to understand that code" :( 20:57:59 <aleth> yeah... 20:59:33 <aleth> The problem is putting the unread ruler between context and non-context messages on opening the conversation runs counter to the way the code was structured originally. 21:00:06 --> Tomek has joined #instantbird 21:00:08 <flo> what bad thing happens if you don't change this test to this: "if (setUnreadFlag && !this._haveContextMessages) {" ? 21:01:29 <aleth> Then the flag on the tab may be set just after you open a conversation from hold. It would then stay set until you switch away from the tab _and_ switch back to it. So it breaks being notified of new messages. 21:02:09 <Mic> This doesn't really sound like fun :( 21:02:25 <flo> wait, is _haveContextMessages used only to work around the fact that _readCount isn't reset at the end of _showFirstMessages? 21:03:53 <aleth> No, that's not it. One issue is that there may be system messages among the "new" messages which visually should belong to the context messages but are not counted in _readCount. 21:05:52 <aleth> Though one could maybe do something clever with readCount to get around that, I'm not sure that would be more legible. 21:09:08 <flo> I think I still don't understand the bug you were seeing before all these changes :-/ 21:10:32 <aleth> When you say "reset" in "is _haveContextMessages used only to work around the fact that _readCount isn't reset at the end of _showFirstMessages", do you mean deleted? 21:11:15 <flo> delete, or set to 0 or whatever value doesn't get in the way 21:13:14 <aleth> Probably possible, but then you are just replacing the presence/absence of _haveContextMessages with the difference between readCount== 0 and undefined I think. 21:14:05 <-- clokep_work has quit (Quit: http://www.mibbit.com ajax IRC Client) 21:14:35 <aleth> I guess I'll take another look and see if the booleans can be grouped better so things are clearer... 21:14:40 <flo> I think it would help if I could understand what this patch is trying to fix. "The ruler was being added to the DOM synchronously, while the messages are added asynchronously." doesn't really make sense to me. Both seem to be added synchronously, both before and after the patch. 21:15:39 <aleth> Oh, that's a bit we haven't even talked about. That just refers to setUnreadRuler being moved from conversation.xml to convbrowser. Convbrowser has the progress bar staggering, that's what I meant by asynchronous. 21:16:21 * flo is even more confused 21:16:26 <aleth> That really is a bug in the existing code which just wasn't noticed so far. 21:17:58 <aleth> appendMessage in convbrowser doesn't immediately add the message to the DOM, it adds them to a list which is then added bit by bit. So if conversation.xml sets the unread ruler just because it's sent n appendMessage calls, it will quite possibly insert the ruler in the wrong place. 21:18:55 <-- BYK2 has quit (Quit: Instantbird -- http://www.instantbird.com) 21:19:26 <flo> aaaah! 21:19:40 <flo> I didn't remember the queue had been moved from conversation.xml to convbrowser.xml 21:20:02 <aleth> nor did I when I wrote the unreadruler code ;) 21:20:58 <flo> is the added sort call yet another unrelated bugfix? 21:21:07 <aleth> No. 21:21:30 <aleth> That's because in the existing code, there is no way the unread ruler can be above the first noncontext message. 21:22:34 <-- chrisccoulson has quit (Quit: Ex-Chat) 21:22:50 <Mic> Good night 21:22:55 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 21:23:18 <flo> isn't the unread ruler always either at the same position as the first noncontext message, or further down? 21:24:01 <flo> hmm, with some padding/margin difference 21:24:05 <aleth> Yes, but in terms of coordinates it may be above it. Probably would make no difference given the way section scroll works, but better to do it cleanly. 21:25:00 <flo> ok 21:28:53 <flo> is the unread ruler between context and non context going to disappear after the conversation is unfocused and refocused? Will that join the last context bubble with the bubble after it? 21:29:44 <aleth> it will disappear as usual, but it won't rejoin those bubbles. 21:30:00 <flo> ok :) 21:36:14 <-- Guido has quit (Quit: Instantbird 1.1) 21:37:29 * bear is now known as bear-afk 21:37:58 <flo> aleth: the change with --this._readCount is just to fix the value of _isAfterFirstRealMessage? 21:38:55 <aleth> The meaningful change there (that has to be kept) is moving if(...)this._isAfterFirstRealMessage = true; above if(read) 21:39:19 <flo> ok, that's what I just understood :) 21:39:25 <aleth> OK :) 21:41:18 <aleth> If one didn't care about seeing an unread ruler when opening a conversation from hold, that would be the only change necessary for the bug. 21:41:32 <flo> so, if you get rid completely of _haveContextMessages, revert the change to the way setUnreadFlag is set, change the way firstUnread is set so that it can doesn't care about the tab being selected/focused when this._readCount == 0, revert the change to _readCount that can make it be negative and only keep the move. Is anything broken? 21:43:10 <flo> "so that it can doesn't care" -> ignore the "can" here :) 21:44:23 <aleth> I'll have to check. You'd have to distinguish between _readCount==0 and undefined I think. Otherwise you'd get the unread ruler popping up all the time in the open conversation as new messages arrive. 21:45:20 <aleth> (undefined would denote we are not adding the first messages anymore) 21:48:29 <flo> so maybe we need to store this._firstUnread = true when displaying a message with firstUnread = true, and reset that to false when the conversation is no longer displayed? 21:50:29 <aleth> I think I see what you are getting at, but I don't like the implementation. 21:50:43 * bear-afk is now known as bear 21:50:43 <aleth> You mean "just check if there is already an unread ruler" 21:51:25 <aleth> I think? 21:52:52 <flo> maybe, yes 21:53:05 <flo> if that gives us something readable 21:53:08 <-- jb has quit (Ping timeout) 21:53:26 <aleth> Life was easier without the request to have the unread ruler between context and noncontext messages ;) 21:53:44 <aleth> I'll have to think about it another day to see if it will break something else 21:55:01 <flo> aleth: sometimes to keep one's sanity, it's good to ignore some requests ;) 21:56:04 * flo will shamelessly ignore the requests to add tests to gloda's search result view :-P 21:56:43 <aleth> heh :D 21:56:43 <aleth> gloda sure sounds like its real fun to work with :-S 21:56:46 <flo> aleth: would it simplify things if we landed this evening the fix for the existing bug? It shouldn't be difficult to split out of the current patch, right? 21:57:03 <aleth> Yes, I was just thinking the same thing, splitting that off 22:01:53 --> mmkmou has joined #instantbird 22:02:49 <-- micahg has quit (Ping timeout) 22:03:11 <aleth> flo: http://pastebin.instantbird.com/36435 22:03:45 <flo> keep the let firstUnread = <real value> change? 22:03:54 <aleth> oh right. 22:03:59 <aleth> Too much undo ;) 22:08:03 <aleth> http://pastebin.instantbird.com/36437 22:09:44 <flo> ok :) 22:11:38 <flo> what's the commit message for that? :) 22:12:34 <aleth> "Set unread ruler at the same time as the following message is added to the DOM"? 22:12:37 <flo> "display the unread ruler at the correct place even if messages were queued for asynchronous display when the first unread message arrived." is this accurate? 22:13:12 <aleth> Yes, that's better, describes the bug too. 22:13:32 <flo> I guess I can still reference bug 1415 22:13:35 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1415 nor, --, ---, aletheia2, ASSI, Unread ruler should also appear after last context message 22:15:39 <flo> I wonder if I can finish bug 1416 quickly 22:15:46 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1416 nor, --, ---, nobody, NEW, JS-XMPP MUCs are duplicated after rejoining 22:15:49 <flo> that bug really annoys me everyday :-| 22:16:30 <aleth> Especially if you get disconnected quite often :-/ 22:17:33 <flo> it would be nice to discover why our socks never timeout, but that's not really related :) 22:17:36 <flo> *sockets 22:17:57 <aleth> I had a brief look at sending messages to offline accounts btw, and suspect it applies to all JS protos 22:18:03 <flo> I have a netsoul account that's been displaying "Connecting: Connectingâ¦" for 3 hours 22:18:15 <aleth> But I'm not sure as I don't use JS-XMPP 22:18:32 <flo> what do you mean with "sending messages to offline accounts"? 22:18:54 <flo> ah, the lack of user feedback? 22:18:58 <aleth> Uh, that doesn't sound good. 22:19:05 <flo> did we even do that for libpurple accounts? 22:19:14 <aleth> bug 1353 22:19:17 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1353 nor, --, ---, nobody, NEW, No user feedback when sending a message in a conversation of an offline account 22:19:37 <aleth> libpurple accounts refuse to send the message (when you press return, nothing happens) 22:20:19 <aleth> This is feedback of a sort. 22:20:42 <flo> ah, that means sendMsg throws? 22:20:49 <aleth> I think so. 22:21:03 <aleth> I didn't look any deeper into the libpurple code. 22:22:22 --> Kaishi has joined #instantbird 22:23:05 <flo> I've just tested the attachment in bug 1416, it seems to work fine. 22:23:18 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1416 nor, --, ---, nobody, NEW, JS-XMPP MUCs are duplicated after rejoining 22:23:24 <aleth> :) 22:23:32 <flo> I wonder if I can just check it in or if I should wait for clokep to review it. 22:24:15 <flo> or do you want to r+ it? :-D 22:24:58 <aleth> I don't know JS-XMPP at all, so there is little point ;) 22:25:23 <aleth> You could always check it in and file follow-ups if it isn't a complete fix. 22:25:28 <flo> yes, and you aren't officially a peer of chat/ for Thunderbird 22:26:05 <aleth> ah of course, it's in chat 22:26:25 <flo> aleth: I could check it in for Instantbird, but I'm annoyed at the idea of wanting to import the patch in Thunderbird later 22:26:46 <aleth> clokep might show up in a few minutes... 22:31:36 <-- sonny has quit (Ping timeout) 22:34:57 <flo> instantbot: review my patch 22:35:00 <instantbot> flo: Sorry, I've no idea what 'review my patch' might be. 22:35:01 <instantbot> flo: Your patch looks good. r+sr+ui-r+a=mconnor 22:35:20 --> sonny has joined #instantbird 22:36:35 <aleth> unexpected,yet convenient... :D 22:36:47 <flo> aleth: I didn't expect the first reply 22:37:08 <flo> aleth: I thought it was going to ask his friend firebot before saying stupidly that it doesn't know 22:42:22 <instantbot> florian@instantbird.org requested review from clokep@gmail.com for attachment 1425 on bug 1416. 22:42:24 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1416 nor, --, ---, nobody, NEW, JS-XMPP MUCs are duplicated after rejoining 22:44:59 <-- aleth has quit (Input/output error) 22:45:11 --> clokep has joined #instantbird 22:45:11 * ChanServ sets mode +o clokep 22:45:42 <flo> ah :) 22:45:48 --> aleth has joined #instantbird 22:45:48 * ChanServ sets mode +h aleth 22:47:07 <flo> do we have a bug on file for the without-steps-to-reproduce-but-confirmed issue of "I can't connect any socket until I restart the application"? 22:47:53 <aleth> I don't think so. Mic might know... 22:48:42 <-- Tomek has quit (Quit: Instantbird 1.1) 22:48:51 <clokep> I don't think so either. 22:50:51 <-- flo has quit (Ping timeout) 22:56:45 --> flo has joined #instantbird 22:56:45 * ChanServ sets mode +qo flo flo 22:57:02 <flo> surprising how just when I was talking of that bug it actually happened :-S 22:58:19 <flo> it's bug 1355 22:58:25 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1355 maj, --, ---, nobody, UNCO, After extended period of time, MSN and checking for updates stop working 22:58:43 <aleth> needs retitling then... 22:59:33 <-- myk has quit (Ping timeout) 23:04:35 <instantbot> New Core - Eventloop bug 1422 filed by florian@instantbird.org. 23:04:37 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1422 maj, --, ---, nobody, NEW, Connection timeouts don't seem to work 23:07:31 <flo> aleth: I don't see anything in the code preventing from sending a message to a disconnected libpurple account 23:08:36 <aleth> That's the behaviour I get though, for MSN and XMPP at least. 23:08:48 <flo> ok, the error console gives the solution: "Error: uncaught exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [prplIAccount.HTMLEnabled]" 23:09:11 <aleth> Ah yes. Sorry, should have spotted that. 23:09:13 <flo> it's the call at http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#309 that throws 23:09:27 <aleth> I thought the throw was intentional from libpurple. 23:10:03 <flo> I think we can just if (!account.connected) return; just above that line 23:10:32 <aleth> That should do it :) 23:11:00 <aleth> Though there are ways the UI might try to send a system message I suppose 23:11:24 <flo> the system message would be some code before that "return;" 23:13:19 <flo> do we want to print "Your computer seems offline" or "Your <protocol> account <name> is not connected." depending on whether the user can go to the account manager to fix the situation? 23:14:30 <flo> clokep: how does that xmpp patch sound? 23:14:52 <aleth> Might be nicer than merely "breaking" the return key :) 23:14:52 <clokep> flo: When I looked at it when you first put it up it looked OK. 23:14:58 <clokep> I haven't looked today though, I just got home / making dinner. 23:19:50 <instantbot> clokep@gmail.com granted review for attachment 1425 on bug 1416. 23:19:54 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1416 nor, --, ---, nobody, NEW, JS-XMPP MUCs are duplicated after rejoining 23:22:50 <flo> "I like simple fixes like this!" it's clear that it's not a fix that's going to make your head hurt :) 23:23:18 <flo> thanks for the quick review :) 23:23:25 <clokep> You're welcome. Sorry I didn't do it earlier. :) 23:24:16 <flo> I requested review on it only this evening, after taking the time to actually test it 23:26:45 <instantbot> florian@instantbird.org set the Resolution field on bug 1416 to FIXED. 23:26:48 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1416 nor, --, 1.2, florian, RESO FIXED, JS-XMPP MUCs are duplicated after rejoining 23:27:03 <flo> Good night :) 23:27:18 <clokep> 'night! 23:27:31 <-- flo has quit (Quit: Instantbird -- http://www.instantbird.com) 23:28:16 * bear is now known as bear-afk 23:30:38 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/ec1dde7b6d05 - Florian Quèze - Bug 1416 - JS-XMPP MUCs are duplicated after rejoining, r=clokep. 23:30:39 <instantbot> Check-in: http://hg.instantbird.org/instantbird/rev/ab4e62cebafa - aleth - Bug 1415 - display the unread ruler at the correct place even if messages were queued for asynchronous display when the first unread message arrived, r=fqueze. 23:43:50 * clokep wonders if aleth is still awake... 23:44:07 <aleth> just... 23:45:33 <clokep> Ah OK. Then I'll leave you a present for the morning... 23:46:08 <aleth> ok :) 23:46:15 <clokep> re: bug 1366 23:46:18 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1366 maj, --, 1.2, clokep, RESO FIXED, Inform the user when attempting to send a message to an offline nick 23:46:26 <clokep> Uhhh.... 23:46:32 <aleth> uhh i hope not 23:46:32 <clokep> Bug 318 :) 23:46:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=318 enh, --, ---, clokep, ASSI, Check if topic on IRC channels is editable and make UI respond accordingly 23:48:58 <clokep> Well it seems to work... 23:49:09 <-- Kaishi has quit (Quit: Kaishi) 23:49:11 <aleth> :) 23:50:25 * clokep is satisfied... 23:50:29 <aleth> Btw I was wondering if bug 1308 (and its consequence, bug 1309) shouldn't be 1.2-wanted 23:50:34 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1308 nor, --, ---, nobody, NEW, Errors on joining channel: "Adding a chat buddy twice" 23:50:35 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1309 nor, --, ---, nobody, NEW, Error: Removing or updating a nick that is not in the room 23:50:45 <clokep> Right. :-/ 23:50:57 <aleth> Those are not nice bugs :( 23:51:39 <aleth> At least I haven't got a good idea how to fix them 23:52:42 <clokep> I know. 23:53:13 <clokep> I have no idea either. :( 23:53:24 <instantbot> clokep@gmail.com requested review from aletheia2@fastmail. fm for attachment 1432 on bug 318. 23:53:28 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=318 enh, --, ---, clokep, ASSI, Check if topic on IRC channels is editable and make UI respond accordingly 23:53:42 <clokep> That actually turned into not an awful patch... 23:53:47 <clokep> It was very messy at first. 23:53:57 <aleth> Yes, the refactoring really made it nice :) 23:55:37 <aleth> You could move this to the participant setMode too: conversation.notifyObservers(convChatBuddy, "chat-buddy-update"); 23:56:05 <aleth> (I think) 23:56:42 <clokep> Actually everything inside the "notify the UI of changes" could be moved there. ;) 23:56:50 <clokep> (And probably makes sense to be in there... 23:56:52 <clokep> ) 23:56:54 <aleth> Even better :) 23:57:23 <clokep> I dislike that I have to give the conversation into that method though. It seems that the participants don't have a reference back to a conversation! 23:57:30 <clokep> s/to a/to their/ 23:57:53 <aleth> I was just wondering about that. I suppose they may be in more than one. 23:58:11 <aleth> or are they duplicated? I forget 23:59:40 <clokep> Yes. 23:59:43 <clokep> They're unique per conversation. 23:59:48 <clokep> (They can have different properties.) 23:59:52 <clokep> I'm Op in here, but no in #maildev.