#instantbird log on 03 23 2011

All times are UTC.

00:12:34 <clokep> So flo I'm like half way through porting that but I can't seem to find a browser window. :-/ I'll talk to you about it toomrrow.
00:24:13 <-- Orn has quit (Ping timeout)
00:27:10 --> Ornthalas has joined #instantbird
01:36:56 <-- GeekShadow has quit (Quit: The cake is a lie !)
01:40:04 <-- Ornthalas has quit (Quit: KTHXBYE)
01:58:13 --> Mook has joined #instantbird
02:30:10 <-- clokep has quit (Quit: Instantbird 0.3a2pre)
05:08:46 <-- rikki has quit (Ping timeout)
05:11:59 --> rikki has joined #instantbird
05:21:32 --> waynenguyen has joined #instantbird
05:26:20 <-- waynenguyen has quit (Quit: Instantbird 0.2)
05:26:24 --> waynenguyen has joined #instantbird
05:37:36 <-- micahg has quit (Ping timeout)
05:41:28 --> micahg has joined #instantbird
05:43:44 <-- waynenguyen has quit (Ping timeout)
05:45:18 <-- micahg has quit (Ping timeout)
06:06:37 --> mepine has joined #instantbird
06:50:24 <-- skeledrew has quit (Ping timeout)
06:53:40 --> skeledrew has joined #instantbird
07:00:30 <-- skeledrew has quit (Ping timeout)
07:11:06 --> GeekShadow has joined #instantbird
07:42:53 <-- Mook has quit (Quit: ChatZilla 0.9.86-xr [XULRunner 2.0b13pre/20110304030406])
07:58:39 --> tymerkaev has joined #instantbird
08:18:29 --> waynenguyen has joined #instantbird
08:25:23 --> Ornthalas has joined #instantbird
08:41:15 <-- tymerkaev has quit (Ping timeout)
08:43:14 --> tymerkaev has joined #instantbird
09:01:07 --> flo has joined #instantbird
09:01:07 * ChanServ sets mode +qo flo flo 
09:11:55 --> Even has joined #instantbird
09:11:55 * ChanServ sets mode +o Even 
09:29:30 <-- Ornthalas has quit (Ping timeout)
09:29:31 <flo> the waterfall looks sad :(
09:35:21 --> Ornthalas has joined #instantbird
09:38:05 <-- Ornthalas has quit (Ping timeout)
09:42:48 --> Ornthalas has joined #instantbird
09:44:31 <-- Ornthalas has quit (Ping timeout)
10:05:14 --> Ornthalas has joined #instantbird
10:08:30 <-- Ornthalas has quit (Ping timeout)
10:09:19 --> Ornthalas has joined #instantbird
10:16:59 --> clokep has joined #instantbird
10:17:00 * ChanServ sets mode +h clokep 
10:19:02 --> Orn has joined #instantbird
10:19:30 <-- Ornthalas has quit (Ping timeout)
10:20:19 <clokep> Good morning. :)
10:34:06 <clokep> Are the build-system changes tha tjust got checked in going to affect us? :-X
10:35:41 <-- mepine has quit (Quit: mepine)
10:36:48 <clokep> (By just I mean sometime in the last 8 hours. :))
10:42:54 <flo> what are they?
10:49:16 <flo> ok, there's a post on planet about this
10:50:32 <clokep> Yes, sorry -- walked away from my computer.
11:00:52 <-- clokep has quit (Quit: Instantbird 0.3a2pre)
11:44:26 --> clokep_work has joined #instantbird
11:44:26 * ChanServ sets mode +h clokep_work 
12:04:45 <-- waynenguyen has quit (Ping timeout)
12:32:30 <clokep_work> So the extension install errors all want to pop up the notification box of the assumed browser that the addon manager is loaded in...but we don't load it inside of a browser or whatever, we just load the straight xul page.
12:33:11 --> sonny has joined #instantbird
12:36:41 <-- sonny has left #instantbird ()
12:36:42 --> kaie2 has joined #instantbird
12:37:36 <-- kaie has quit (Ping timeout)
12:37:38 * kaie2 is now known as kaie
13:00:36 --> skeledrew has joined #instantbird
13:10:24 --> zachlr has joined #instantbird
13:24:35 <-- clokep_work has quit (Connection timed out)
13:27:03 --> clokep_work has joined #instantbird
13:28:23 <-- GeekShadow has quit (Quit: http://www.mibbit.com ajax IRC Client)
13:31:51 --> igorko has joined #instantbird
13:38:22 <flo> clokep_work: any suggestion for what we should do?
13:38:34 <clokep_work> Open a dialog? :p
13:39:02 <clokep_work> It's possible we could wrap the add-on stuff into our own browser element with a notification thing, etc.
13:39:05 <clokep_work> But that's kind of gross.
13:39:14 <clokep_work> I'm going to attempt to generate an overlay that does what I want tonight. :)
13:39:33 <flo> load the add-on manager from a browser in a chrome://instantbird/content/addons.xul file?
13:39:54 <flo> (with a notificationbox in the same xul window)
13:43:37 <clokep_work> That was my first thought.
13:43:52 <clokep_work> Idk how well that'll handle if you wantt o jump to a specific page, etc.
13:46:55 <clokep_work> (Which right now you give it extensions.xul?<some parameter>=(extensions|themes...))
13:47:11 <clokep_work> So either that or adding a notification box in an overlay I think would be best. :)
13:47:17 <clokep_work> Unless you have another idea?
13:51:19 <clokep_work> Did you decide about the core conversation handling?
13:51:52 <flo> yes. I'll rewrite it in JS.
13:51:59 <flo> I wasn't satisfied with my patch :)
13:52:24 <-- Even has quit (Quit: Instantbird 0.3a2pre)
13:52:35 --> Even has joined #instantbird
13:52:35 * ChanServ sets mode +o Even 
13:52:46 <clokep_work> I figured as much since nothing was checked in yet. :-D
13:52:55 * clokep_work feels like 0.3 is a rewrite.
13:53:50 <flo> 0.2 was too in some ways.
13:55:11 --> sonny has joined #instantbird
14:00:02 <clokep_work> Right. :) Not that it's bad mind you. Just keeps things fluid.
14:02:43 <flo> it's bad in the sense that it's way too slow ;)
14:03:17 <clokep_work> Well hopefully things are getting much more into an incremental state.
14:03:39 <clokep_work> And it's better to rewrite now than to hack around stuff.
14:22:22 <clokep_work> I'm pretty excited for being able to keep the same conversation over multiple buddies though. :-D I have a lot of friends I'll start a conversation on one network and than change as they move location.
14:23:11 <flo> so you also need the automatic switch to the most available buddy to be excited about the change, don't you? ;)
14:24:33 <clokep_work> Uhh...yes, probably. :)
14:24:35 <Even> This is obvious :P
14:24:41 <clokep_work> Is it going to notify of switches btw?
14:25:13 <clokep_work> (Like a system message I mean.)
14:25:16 <Even> @clokep_work: I think it should not. This is good for geeks to know but the average user only cares about it working.
14:25:36 <Even> @clokep_work: Maybe an extension to notify about those would be a better idea.
14:26:01 <clokep_work> Even: Fair enough. Maybe a notification can be fired at least so I can write said extension? :-D
14:26:26 <flo> clokep_work: yes.
14:26:41 <flo> and I finally found a solution that I'm mostly satisfied of to decide when to switch
14:26:48 <Even> @clokep_work: well, firing an event is an obvous thing to do in such a case
14:27:17 <flo> I want to avoid switching several times in a row if your contact connects a multi-protocol client and the buddies all come online within a few seconds
14:28:44 <Even> flo: well, I think it's probably better to do so indeed but also maybe not that important : I don't think someone would have a lot of times to send enough messages so they are scaterred everywhere on the recipient's computer
14:28:47 <flo> I'll switch 30s after the preferred (= most available) buddy has changed... but switch immediately if the local user starts typing. This will avoid switching several time when a contact with several buddies come online, and will also avoid sending messages to the wrong buddy
14:29:09 <flo> Even: the problem is we will display a system message for each switch
14:29:49 <flo> ah, I missed half of the previous discussion
14:30:42 <Even> :)
14:31:22 <flo> even if we don't display a system message (but I think we will display one), having the UI changing several times in a few seconds would still look bad
14:31:49 <Even> In this case, the extension could time for 2 or 3 seconds before displaying the switch allowing thus to only print the last one if several switches occurs quickly enough.
14:32:06 <Even> Why should the UI change ?
14:32:24 <flo> the system message could be something like "The conversation will continue on <protocol> where <contact name> is more available."
14:32:32 <Even> I might miss some of the implications of such a switch.
14:32:48 <flo> Even: we will display the "target" of the conversation at the top of the conversation UI. Where we currently have the topic bar for IRC chat rooms
14:32:55 <Even> The notion of "more available" looks a little amiss.
14:33:01 <Even> But apart from that...
14:33:26 <Even> Define target now :P
14:33:43 <flo> buddy :-P
14:33:57 <Even> Well, why should it change then ?
14:34:06 <Even> Whatever the protocol, the buddy is the same...
14:34:14 <flo> nope
14:34:17 <flo> the *contact* is the same
14:35:23 <Even> Won't it be a little too complex to display buddies ? I thought you were targeting something easy to would hide the protocol notion to people that don't care about it.
14:35:36 <Even> I believe that getting this info on the front would not serve this objective.
14:36:04 <Even> We should center on contacts and make "buddies" something like an "advanced feature".
14:36:33 <flo> it will be just one line inside the conversation binding
14:36:52 <flo> people should still be able to know where the person will receive the message
14:37:24 <flo> and for what is worth, I think each XMPP resource should be listed in the target list, they should not appear as a single item.
14:37:36 <flo> but I won't get that before we rewrite XMPP in JS...
14:37:38 <Even> I'm not even sure that expanding contacts that easily is something we want to keep. It's not useful to look there for anybody. Once contacts are merged, this should be forgotten.
14:38:08 <flo> it needs to be discoverable if we want people to ever merge buddies into contacts
14:38:17 <Even> Yeah I know.
14:38:50 <Even> There should be something easy to discover but preventing something "this advanced" to be presented to the user by default.
14:38:53 <Even> But I don't know what...
14:39:17 <flo> you still have to click to expand a contact. I don't think it hurts
14:39:25 <flo> as long as it's not always visible :)
14:39:51 <flo> we don't persist the fact that a contact is expanded, so I don't think people will take time to expand them again after each restart :)
14:39:59 <Even> We have too much examples of already exsting UIs to be really able to find something different but done well.
14:40:10 <-- tymerkaev has quit (Ping timeout)
14:40:19 <Even> Yeah.
14:40:24 <Even> I'm not saying it is very bad.
14:40:31 <Even> It bothers me a little, that's all.
14:40:47 <flo> the current group/tag mess bothers me much more :)
14:41:00 <Even> I do think that your primary idea (told me so probably month ago) to hide the notion of protocols was kinda cool.
14:41:25 <flo> all we need to do for that is to change the icon for contacts in the list
14:41:46 <Even> When I talk to people that are not very aware of it technologies and so on, I remember very well that the notion of protocol is very unclear.
14:42:01 <Even> People quite don't get the difference between a protocol and its default client.
14:42:18 <Even> And when they get it, they don't understand why they can't write to someone else that does not have the same client as they do.
14:44:13 <Even> I don't know what we should do about this but I suppose there will be improvements and cool ideas to be found in this area to hide better that protocols exists.
14:44:30 <Even> It should probably stay something technical that user's don't have to care about.
14:44:35 <clokep_work> I'm not sure I like removing the icons from the buddy list, it's good information to quickly know for me sometimes. But I think even is right for "most" people.
14:44:57 <Even> The best thing we could do in this expense would be to find a way to remove the  "choose the correct protocol" step in creating the account.
14:46:16 <flo> Even: the import wizard ;)
14:46:21 <Even> But I'm not sure it is even possible to try to decuce which protocol it might be depending on the username format and to ask for every server we have and that can possibly have an user with this identifier if they know about it.
14:46:43 <Even> So if something of the like is possible, would be quite cool.
14:46:49 <Even> *But
14:47:15 <Even> "creating account / adding a contact
14:47:22 <Even> should be able to use the same mechanism
14:47:29 <Even> first one is easier
14:47:56 <Even> you ask for username / password, you check if you can connect to any of the servers you can handle, if yes you add the correspondign account.
14:48:24 <Even> Might be pretty cool.
14:48:26 <flo> what if the user uses MSN and XMPP with the same email address?
14:48:37 <Even> and the same password ?
14:48:40 <flo> yes
14:48:41 <Even> you add both accounts at once...
14:48:44 <Even> Even better :P
14:49:04 <flo> so you keep connecting (and sending the password!) to random servers until you have tried all the servers you know about?
14:49:11 <Even> Yep.
14:49:36 <Even> "random", is the username looks like "0143545" you can go for ICQ and forget the others :P
14:49:43 <clokep_work> That sounds dangerous. :-/
14:49:54 <Even> Don't think so.
14:50:16 <Even> Protocols don't have the habit to use clear text versions of the passwords.
14:50:19 <Even> And they use secure channels.
14:50:39 <flo> Even: so you ignore QQ and GG?
14:51:01 <Even> Well, you ignore all those that do not ave secure connexion mechanisms.
14:51:15 <Even> We can go for seomthing like Thunderbird does for email accounts.
14:51:26 <Even> If it fails automatically, you can go for the manual way.
14:51:29 <clokep_work> But that guesses based on the end of the email account.
14:51:39 <flo> we can easily check dns srv records for XMPP accounts
14:51:46 <Even> Yep.
14:51:51 <clokep_work> Also...my MSN account uses my Yahoo email address. ;)
14:51:53 <flo> that's similar to what is done for emails
14:52:02 <Even> I think it would be a very nice way to hide protocols a lot better.
14:52:11 <flo> clokep_work: and your yahoo account uses an MSN address? :)
14:52:33 <Even> (it would be very funny :P)
14:53:26 <Even> Well, I'm not saying those are good ideas, I'm only trying to see if there is room for improvements in those wizards.
14:53:38 <clokep_work> flo: Nope, my Yahoo also uses my Yahoo. :)
14:53:52 <Even> I think the step that is the most likely to get us lose users because they don't quite get it is the "choose your protocol".
14:53:55 <clokep_work> Even, I think it's a great idea. I'm just trying to make sure we're not caught up on technical details.
14:53:55 --> waynenguyen has joined #instantbird
14:54:05 --> tymerkaev has joined #instantbird
14:54:13 <Even> If the user was just asked for username / password to create its account, it might be a lot easier on him.
14:54:17 * clokep_work wonders if we can even import from the official clients...
14:55:14 <Even> @clokep_work: yeah, might be easier to detect as I suggest than to keep & maintain a working import mechanism with all those clients softwares
14:55:58 <Even> flo: what are your thoughts about all this ?
14:56:09 <flo> Even: I don't think we should try to guess where to send the password
14:56:29 <flo> I would say: 1. If the user has no clue what a protocol is, the best guess is to import the accounts of existing clients.
14:56:36 <Even> So we keep asking the correct protocol ?
14:56:42 <flo> 2. If the user has really no clue, create a new XMPP account on an instantbird server.
14:57:15 <Even> And what if he has no clue and a new version of MSN we don't quite handle as of the moment he tries ?
14:58:21 <flo> then he has no clue and no luck
14:58:30 <Even> I'm not saying we should send the password randomly, but select servers that have authentication mechanisms that looks serious enough so we might do it. I think most of the major ones (except QQ) are probably good enough.
14:58:31 <flo> but maybe a clever grand-son who will help
14:58:44 <clokep_work> Don't the protocol names/icons match the official clients pretty well though?
14:58:52 <clokep_work> I don't see picking from a list as that difficult?
14:59:03 <flo> for people who have absolutely no clue, it's unlikely they will download Instantbird themselves, so we can rely a bit on the person who installed it for them :)
14:59:35 <flo> clokep_work: yeah, I think people are likely to recognize the icon they have already seen a lot
15:00:07 <Even> Well, don't tell me you've never seen anyone lost on this particular screen.
15:00:11 <Even> Because I won't believe you.
15:00:20 <flo> I wanted (for 0.2) to trim the protocol list to keep only 4-5 very visible possible protocols with big icons, and a "more..." item at the end of the list to select something strange or download more from AIO
15:00:46 <Even> flo: that's already better than the awfully long list we have now
15:01:15 <flo> Even: well, I haven't witnessed many people with absolutely no clue setting up Instantbird. I know some looked for "Jabber" and couldn't find XMPP though :)
15:01:37 <Even> But I quite don't understand why it would be such a problem to try to connect to the server... It's not likely it will log the username/password couple for each failed attempts it gets.
15:01:52 <flo> Even: yeah, I think that more than the choice itself, the problem is that there are many protocols people have never heard of which make the list seems like complete nonsense
15:01:53 <Even> And even less liekly someone will try to peek into them to see if it might work on other protocols.
15:02:56 <Even> And I don't think most of the major protocols even send the password in a way that can be reversed to get its original form.
15:03:43 <Even> A logical way to do an authentication online should have the server send a mean and the client responding with the password modified using it and a non revesable algorithm.
15:03:46 <clokep_work> flo: Make those visible protocols localizable I think would be good.
15:03:56 <flo> clokep_work: it's a requirement
15:04:00 <clokep_work> Good. :)
15:04:09 <flo> the 5 top protocols are not the same across countries :)
15:04:15 <clokep_work> I don't want to see this QQ junk in the US. ;)
15:04:37 <flo> you don't want netsoul either ;)
15:04:37 <Even> I'm myself more and more getting at saving the md5 on the database of my servers and on authentication using JS to send md5(md5(password) + uniqueid) via HTTP (no need for https there)
15:04:50 <clokep_work> Also libpurple officially added MXit apparently. Not that that really matters for this. :-D
15:05:07 <clokep_work> But just something I noticed.
15:05:08 <flo> yeah. I haven't bothered adding it
15:05:21 <flo> I'm not sure we have that many users from South Africa
15:05:27 <Even> :)
15:06:04 <flo> clokep_work: what should be the visible protocols for the US?
15:06:20 <flo> AIM, Yahoo, Google Talk, Facebook, Twitter?
15:06:33 <flo> is MSN used other there?
15:07:34 <clokep_work> flo: From what I've seen it depends on whehter you're on the east or west coast. :P
15:07:46 <clokep_work> But AIM, Yahoo, MSN, GTalk, Facebook and Twitter probably sounds right.
15:08:23 <clokep_work> I was going to say "and XMPP!" but people who use XMPP probably know to click more. :)
15:08:35 <clokep_work> What about IRC? Or is that a geek thing too and under the "more"?
15:08:37 <flo> hmm, it's probably an easy first bug for anybody concerned with UX :)
15:08:44 <flo> it's a geek thing
15:08:49 <clokep_work> I don't really have a feel for how many people use IRC/XMPP. :-/
15:08:52 <flo> (yes, that's sad ;))
15:09:25 --> GeekShadow has joined #instantbird
15:09:36 <flo> geeks like the "more" buttons. That makes them feel knowledgeable :)
15:12:19 <clokep_work> Haha, very true. :)
15:12:31 <clokep_work> I do like the idea of the automagic Thunderbird thing though...hm...
15:19:25 <-- zachlr has quit (Connection timed out)
15:28:31 --> mepine has joined #instantbird
15:33:49 <-- tymerkaev has quit (Ping timeout)
15:34:24 <-- mepine has quit (Quit: 隨緣也)
15:35:52 --> Mic has joined #instantbird
15:35:52 * ChanServ sets mode +h Mic 
15:37:20 <-- waynenguyen has quit (Ping timeout)
15:37:22 --> waynenguyen has joined #instantbird
15:38:39 <Mic> Sounds like the issue with status changes that I have on buddy status (I don't want to have several messages just because there were fast successive changes in status)
15:41:30 --> burt has joined #instantbird
15:42:29 <clokep_work> And you solved in a similar way right?
15:42:34 <clokep_work> "Wait x seconds."?
15:42:57 <-- chrisccoulson has quit (Ping timeout)
15:44:21 <Mic> Yes, I'm setting a timeout and cancel it if there's a new status change
15:45:27 <Mic> (+ setting a new one of course)
15:51:36 <clokep_work> Makes sense. :)
15:51:40 <clokep_work> Hello burt.
16:01:38 <clokep_work> Bleh, meeting.
16:01:41 * clokep_work is now known as clokep_meeting
16:04:08 --> chrisccoulson has joined #instantbird
16:04:58 <-- skeledrew has quit (Ping timeout)
16:05:03 --> skeledrew has joined #instantbird
16:08:23 <-- chrisccoulson has quit (Quit: Ex-Chat)
16:10:27 <-- GeekShadow has quit (Quit: http://www.mibbit.com ajax IRC Client)
16:13:06 --> chrisccoulson has joined #instantbird
16:15:34 <-- Mic has left #instantbird ()
16:19:48 <-- waynenguyen has left #instantbird ()
16:22:59 --> waynenguyen has joined #instantbird
16:27:04 <-- waynenguyen has left #instantbird ()
16:37:59 --> GeekShadow has joined #instantbird
16:40:42 <-- igorko has quit (Ping timeout)
16:41:38 --> igorko has joined #instantbird
16:42:19 <-- flo has quit (Quit: Instantbird 0.3a2pre)
16:58:39 <-- sonny has left #instantbird ()
16:58:59 * clokep_meeting is now known as clokep_work
17:08:11 <-- Orn has quit (Quit: KTHXBYE)
17:09:05 <-- Even has quit (Quit: Instantbird 0.3a2pre)
17:09:30 --> mokush has joined #instantbird
17:22:00 --> tymerkaev has joined #instantbird
17:47:31 <-- clokep_work has quit (Connection timed out)
17:48:21 --> clokep_work has joined #instantbird
17:48:21 * ChanServ sets mode +h clokep_work 
17:53:18 <-- mokush has quit (Ping timeout)
17:57:10 --> mokush has joined #instantbird
18:09:13 --> micahg has joined #instantbird
18:12:59 * tymerkaev is now known as tymerkaev_away
18:13:04 * tymerkaev_away is now known as tymerkaev
18:23:14 --> linuxwizard has joined #instantbird
18:26:37 <-- mokush has quit (Client exited)
18:29:26 <-- Chaz6 has quit (Ping timeout)
18:43:42 --> Chaz6 has joined #instantbird
18:49:20 <-- burt has quit (Quit: Lost terminal)
18:49:26 <-- tymerkaev has quit (Ping timeout)
19:27:55 <-- GeekShadow has quit (Ping timeout)
19:57:15 --> GeekShadow has joined #instantbird
20:05:43 <clokep_work> So since the contact list has been opened up...there hasn't been any contact. :) Either that or the emails are bouncing. :-/
20:07:31 --> tymerkaev has joined #instantbird
20:11:36 --> Ornthalas has joined #instantbird
20:17:12 --> Mic has joined #instantbird
20:17:12 * ChanServ sets mode +h Mic 
20:20:25 <Mic> hi
20:20:42 --> sonny has joined #instantbird
20:21:23 <Mic> tymerkaev: would you like to take bug 620?
20:21:26 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=620 enh, --, ---, nobody, NEW, Maybe Instantbird could look nicer using Glass on Windows Vista and 7
20:21:34 <Mic> You're interested in styling things if I recall correctly
20:22:21 --> flo has joined #instantbird
20:22:22 * ChanServ sets mode +qo flo flo 
20:22:23 <tymerkaev> maybe
20:22:34 --> DetroitLibertyPenguin has joined #instantbird
20:23:16 <Mic> ok, just wanted to let you know :)
20:23:46 <-- sonny has left #instantbird ()
20:24:11 <-- clokep_work has quit (Quit: http://www.mibbit.com ajax IRC Client)
20:35:53 <-- igorko has left #instantbird ()
20:41:15 <Chaz6> Heya, just discovered a little bug
20:41:27 <Chaz6> The url highlighter misses out a trailing "-" 
20:41:44 <Chaz6> e.g. http://www.example.com/?p=asdf-
20:41:57 <Chaz6> it gets as far as "f"
21:03:39 <-- linuxwizard has left #instantbird ()
21:05:58 <-- DetroitLibertyPenguin has quit (Ping timeout)
21:11:30 --> DetroitLibertyPenguin has joined #instantbird
21:34:51 --> mokush has joined #instantbird
21:34:53 <-- mokush has quit (Client exited)
21:47:28 <-- GeekShadow has quit (Quit: The cake is a lie !)
22:19:36 <-- tymerkaev has quit (Input/output error)
22:20:34 <-- Mic has left #instantbird ()
22:30:23 --> mokush has joined #instantbird
22:30:24 <-- mokush has quit (Client exited)
23:17:21 <-- flo has quit (Quit: Instantbird 0.3a2pre)
23:28:11 --> zachlr has joined #instantbird