Hi, I have to add that if we would use PyMSN we still have troubles mixing mainloops : PyMSN needs a GLib mainloop and a non GTK gui needs its own mainloop. For now, it seems that the only way is to execute a loop of a mainloop regulary... If anyone needs a better/more efficient way that could help things... Phil
Youness Alaoui a écrit : > Just to be clear, as Karel just asked me on msn.. I joined the pymsn team, > yes, but it was a choice totally unrelated to aMSN2.. it was because the > developers became friends and i wanted to help, that's it. > > KaKaRoTo > > On Thu, Jan 17, 2008 at 06:28:44AM -0500, Youness Alaoui wrote: >> Hi Karel, >> Please don't take the following email as offending, I do not try to offend >> you or turn you down on what you're saying or the research you've been >> doing or anything.. BUT : >> Please do not give 'solutions' or 'proposals' or 'if aMSN2 uses...' or any >> other kind of talk about aMSN2's design. This applies to anyone else, and >> unfortunately this is a mailing list thread and not a forum thread so I >> cannot 'lock' the thread, so I'm asking everyone to NOT answer to this. >> The reason is simple, I wrote a lot of code for aMSN2 already, a design was >> made with caution, involving mainly Phil as well as opinions from other >> developers. I had a working/semi-usable aMSN2 ready since last july, but I >> didn't have time to clean it/polish it/finish it, in order to release it... >> The design is done and will not change as we think that this is what aMSN2's >> future should be. We made very thorough decisions involving a LOT of >> research and proof of concepts meant to be thrown away to test various >> theories, we reviewed a lot of solutions and considered all the things that >> aMSN2 needs in terms of usability, performance, development time, team >> involvment, team motivation, knowledge transfer, GUI of course, language, >> libraries to use, etc... >> We made decisions that will most benefit aMSN2 in every aspect considered, >> BUT of course, not everyone can be happy... for example, if we decided to >> use GTK, all QT lovers will rant, if we decided to choose QT, all GTK lovers >> will rant, if we decided to use something all, maybe the whole world will >> rant. The same can be applied to the language. >> For this specific reason, we chose not to disclose anything, because if we >> do, we will generate a huge flame war which will never end and aMSN2 will >> never see the light. We want to avoid flame wars, trolling, etc.. and since >> there will always be someone unhappy about our choices, we will have to >> make a decision for everyone and impose it, force it to the community as >> 'the decision', and not 'the proposal'. And as experience serves, when we >> decide something and implement it, and people try it, it's accepted, if we >> ask about it, noone agrees and nothing gets done (take for example all the >> lengthy discussions we had on the ML and what about the inline spaces thing, >> etc.. once implemented, everyone's happy, and noone is when it's being >> discussed). >> For that reason, we decided to keep it all a secret, and not talk about it. >> And this email will only generate flaming, I already see 10 people getting >> all excited and starting to type about how cool it would be if we chose >> python, and another 10 people writing how python would be a bad choice, and >> let's not talk about all the dbus-haters and/or the people who do not want >> to see telepathy added to the project.. another few people will be happy to >> see telepathy added and will start a flamewar about whether aMSN should be >> multiprotocol or single protocol stating that telepathy will allow us to be >> multiprotocol easily, etc ... It will generate a lot of useless, time >> wasting talk about something that was already designed, decided, and written >> and >> will not change anytime soon. >> >> All I need is to get some free time and get together with Phil and Harry and >> TomH and some other guys involved in aMSN2 and polish the current code we >> have, I don't want to release it as it is because people will start coding >> and will mess things up, so I want to have the full/complete structure of >> the code set up and let people just 'fill in the blanks'. >> >> p.s.: Just for the record, as some of you already know, and you can check >> that on pymsn's website I guess, I'm part of the pymsn team since June I >> think. I met Ali Sabil and Johan Prieur and Ole Andre (the 3 guys behind >> pymsn) in real life at the guadec conference in birmingham and we bonded a >> lot, we had a lot of fun and a lot of talking, and a lot of hacking together >> and they convinced me to help them on pymsn so I joined the project. >> Considering my MSN protocol knowledge, I can help them a lot and I've >> already implemented offline messaging and spaces support into pymsn as well >> as >> a part of the MSNP2P stack in order to allow webcam support. >> >> KaKaRoTo >> >> On Thu, Jan 17, 2008 at 11:35:51AM +0100, Karel Demeyer wrote: >>> Telepathy's officially supported MSN protocol connector (pymsn) now uses >>> MSNP15 too. They're now working on adding support for nudges, custom >>> emoticons audio/video and so on. Still, this looks like a big step as it's >>> a full rewrite. We should keep our eyes and ears open :). >>> >>> If aMSN2 is going to use telepathy, some of us who know MSNP and python that >>> are not into C could go on like this ;) Personally I think that such a >>> protocol implementation in python makes a lot of sense as we've seen the >>> protocol change often and, IMO, it's more "rapid" (as in RAD) to adapt >>> python code then it is in C-code, though I'm not an expert :). >>> >>> Now if we only had tcl/tk-dbus bindings we could still have our interface >>> (which would be what amsn is then ?) in tcl/tk :p ... but that discussion >>> might have been closed already :). >>> >>> Karel. >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Amsn-devel mailing list >>> Amsn-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
