Re: [Amsn-devel] aMSN2 and Telepathy
On Sun, Aug 29, 2010 at 12:01, Arantes arantes...@gmail.com wrote: Hello guys, Just wanted to say ... I really don't like this. Not because of the use of DBUS, or the multiprocess or not, but because i really think that if we do that, aMSN won't be aMSN no more. It would just be another multi protocol client, like there are tons of. I really think aMSN should stay a msn-only client, that's how it can be the best at it. Of course aMSN2 should stay focused on msn. But the only need of multi protocol i have is to be able to chat with my parents and my sister and have audio/video conversations with them since they use gchat. That's all i need and i think that's all i'll ever try/work on. I'll still use irssi for irc for example. As Youness stated, it's not really a big change. -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Hello guys, Just wanted to say ... I really don't like this. Not because of the use of DBUS, or the multiprocess or not, but because i really think that if we do that, aMSN won't be aMSN no more. It would just be another multi protocol client, like there are tons of. I really think aMSN should stay a msn-only client, that's how it can be the best at it. Besides that, i can't really have an opinion about that dbus and telepathy stuff, cause i don't know enough about that, but i can't understand why making amsn2 able to switch FE would need a client daemon structure. Why couldn't we just keep the same structure as now and add to the core the ability to kill a front end, then launch another one ? Of course we would need to implement a lot of stuff, like that the core should not only pass all the messages to the FE but also keep them to be able to re send them to the potential new FE.. That would be simpler than rewriting almost the whole protocol abstraction layer to make it compatible with a telepathy backend, wouldn't it ? Le 27 août 2010 à 02:23, Alaoui kakar...@kakaroto.homelinux.net a écrit : On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure bill...@gmail.com wrote: 2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Well, aMSN2 has always been a telepathy-like framework, with small difference... first, it's uni-process, secondly, you don't give UIs any information they don't need, you just tell them what to draw where as telepahy tells the UI all the information and the UI decides what to do with it (which is important for their use case). So the real question is since we're doing pretty much what telepathy does.. should we drop our uniprocess requirement? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. With dbus it just works, you request a service, and the dbus daemon will spawn the process for you.. same when the process dies, the dbus daemon will respawn it automatically for you if you still want it. @Stephane: About the dbus requirement, well that's not really the issue.. yes, now pretty much every computer has it.. oh look, even my headless server! And even if you don't have it.. once you apt-get install amsn, it would just be brought along with it... Also, GNOME now has empathy as its default IM client. So that means that every GNOME user already has telepathy. Anyways, the size doesn't matter, the dependencies don't matter.. the only reason (for me anyways) to say not like the dbus dependency is because I don't like dbus itself, not because of the dependency... There was also an issue of would it work on windows but afaik, it's windows-compatible (TM). Finally, I'd like to point out that even though dbus is a bitch to work with, we'll be using python.. and python-dbus is JUST AWESOME! Very easy to use actually.. and as luck would have it, a few months ago, I wrote a big python framework to make the use of telepathy/dbus as easy as possible. Have a look here : http://gitorious.org/teamgeist/teamgeist/blobs/master/tp_classes.py Basically.. you want a Channel, then do : class Channel (BaseChannel): you want to listen to the 'HandleChannel' dbus signal, then do : method HandleChannel ( ... ) that's it.. the base classes will look for the method names, and automatically do introspection on the objects and connect the signals, or send the dbus methods when you call a local method, etc... so, actually dbus + python.. I don't mind that dependency that much... -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this
Re: [Amsn-devel] aMSN2 and Telepathy
On Sun, Aug 29, 2010 at 6:01 AM, Arantes arantes...@gmail.com wrote: Hello guys, Just wanted to say ... I really don't like this. Not because of the use of DBUS, or the multiprocess or not, but because i really think that if we do that, aMSN won't be aMSN no more. It would just be another multi protocol client, like there are tons of. I really think aMSN should stay a msn-only client, that's how it can be the best at it. Yes, we know that, we already do, and that's why we always wanted aMSN to stay MSN specific, and I don't think we plan on stopping that! the multiprotocol is a 'bonus', but we'll stay MSN-centric, we'll continue to support the MSN protocol as much as possible, the UI will stil keep the WLM lookfeel, etc... we'll just change the protocol backend/technology, which itself allows us to go multi proto... Besides that, i can't really have an opinion about that dbus and telepathy stuff, cause i don't know enough about that, but i can't understand why making amsn2 able to switch FE would need a client daemon structure. Why couldn't we just keep the same structure as now and add to the core the ability to kill a front end, then launch another one ? Of course we would need to implement a lot of stuff, like that the core should not only pass all the messages to the FE but also keep them to be able to re send them to the potential new FE.. Because you can't.. if you launch the process somewhere for the GTK/QT frontends, then connect through ssh then you can't just ask it to start sending the curses front end on your terminal... That would be simpler than rewriting almost the whole protocol abstraction layer to make it compatible with a telepathy backend, wouldn't it ? nah, the 'whole protocol abstraction' is quite small and simple, we're not rewriting the whole protocol, just the protocol layer. Look at amsn2/protocol/client.py ( http://github.com/amsn/amsn2/blob/master/amsn2/protocol/client.py ).. that's pretty much all we need to rewrite... there are some files in events/ subdir, but look at them.. not much.. so when you say rewriting almost the whole protocol abstraction layer I don't think it's too much of an issue compared to the gain. An advantage of telepathy, is for example when you said we need the core to save the messages in order to pass them back to the new FE.. there's no need for that.. we could use the telepathy-logger! amsn2 itself doesn't need to be saving logs, because telepathy has its own 'logger' process which acts as an 'observer' on the channels.. so if you wish to switch front-ends, you can just ask it to re-print it the last X lines of conversation or something. (and btw, it gives us the advantage that the logs will be in the same format and compatible with empathy, etc.. ) Le 27 août 2010 à 02:23, Alaoui kakar...@kakaroto.homelinux.net a écrit : On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure bill...@gmail.comwrote: 2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Well, aMSN2 has always been a telepathy-like framework, with small difference... first, it's uni-process, secondly, you don't give UIs any information they don't need, you just tell them what to draw where as telepahy tells the UI all the information and the UI decides what to do with it (which is important for their use case). So the real question is since we're doing pretty much what telepathy does.. should we drop our uniprocess requirement? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. With dbus it just works, you request a service, and the dbus daemon will spawn the process for you.. same when the process dies, the dbus daemon will respawn it automatically for you if you still want it. @Stephane: About the dbus requirement, well that's not really the issue.. yes, now pretty much every computer has it.. oh look, even my headless server! And even if you don't have it.. once you apt-get install amsn, it would just be brought along with it... Also, GNOME now has empathy as its default IM client. So that means that every GNOME user already has telepathy. Anyways, the size doesn't matter, the dependencies don't matter.. the only reason (for me anyways) to say not like the dbus dependency is because I don't like dbus itself, not because of the
Re: [Amsn-devel] aMSN2 and Telepathy
I really don't like the dependency on DBUS, but that's the best way to achieve it. My main issue about using telepathy is that we were going to have a kind of preview 0.1 release in september. Should we still aim at that goal? I think we should since we don't know how much time will be needed to integrate telepathy. -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! About the DBus dependency, I think that the only place where it could really be an issue is for people having a server configuration: in desktop environments it is pretty much already required by some other app, whereas servers without an X server probably don't have it installed. Yet there are some other factors to consider: first of all, AFAIK it is not a big dependency, but something quite small. Also, do the most common distributions already include it in their server version? For instance do Red Hat, Suse, Ubuntu server include it by default? Because if it's there, then most of the users will already have met that dependecy requirement, making it pointless to worry about it. Also I don't think that a dependency on DBus is a dealbreaker for anyone, but maybe someone disagrees on that... Here's my 2¢ :) -- Stéphane -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Thu, Aug 26, 2010 at 4:31 AM, Boris 'billiob' Faure bill...@gmail.comwrote: I really don't like the dependency on DBUS, but that's the best way to achieve it. I don't either, but without it, it becomes incredibly difficult to have a client/server mode since we'd need to create our own IPC protocol which is stupid. My main issue about using telepathy is that we were going to have a kind of preview 0.1 release in september. Should we still aim at that goal? I think we should since we don't know how much time will be needed to integrate telepathy. nah, don't worry about it, it can get released as is, then telepathy backend switched on top of it for the future. The technology behind amsn2 doesn't matter for users as long as it works, and amsn2 0.1 is meant for users to try out amsn2, so let them try it, then don't need to know/care if we'll change the underlying protocol abstraction or not. -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Thu, Aug 26, 2010 at 8:45 AM, Boris 'billiob' Faure bill...@gmail.comwrote: 2010/8/26 Stéphane Bisinger stephane.bisin...@gmail.com: I think that if we want to split daemon/client, telepathy is an eccelent option since we would basically do the same thing with an implementation of our own. So the question is: would it be a good idea to split aMSN2 in a client/daemon structure? that's the goal. The way we use views is a bit like client-dæmon anyway. Well, aMSN2 has always been a telepathy-like framework, with small difference... first, it's uni-process, secondly, you don't give UIs any information they don't need, you just tell them what to draw where as telepahy tells the UI all the information and the UI decides what to do with it (which is important for their use case). So the real question is since we're doing pretty much what telepathy does.. should we drop our uniprocess requirement? Based on what I see from the centerim project, a LOT of people use a similar functionality, where you can start centerim in the background and do things from the command line. This is very much like having a daemon and a client which is only command line. With the described structure we would be able to do more and do it better! And if the client can not contact the daemon, it should be able to start it. With dbus it just works, you request a service, and the dbus daemon will spawn the process for you.. same when the process dies, the dbus daemon will respawn it automatically for you if you still want it. @Stephane: About the dbus requirement, well that's not really the issue.. yes, now pretty much every computer has it.. oh look, even my headless server! And even if you don't have it.. once you apt-get install amsn, it would just be brought along with it... Also, GNOME now has empathy as its default IM client. So that means that every GNOME user already has telepathy. Anyways, the size doesn't matter, the dependencies don't matter.. the only reason (for me anyways) to say not like the dbus dependency is because I don't like dbus itself, not because of the dependency... There was also an issue of would it work on windows but afaik, it's windows-compatible (TM). Finally, I'd like to point out that even though dbus is a bitch to work with, we'll be using python.. and python-dbus is JUST AWESOME! Very easy to use actually.. and as luck would have it, a few months ago, I wrote a big python framework to make the use of telepathy/dbus as easy as possible. Have a look here : http://gitorious.org/teamgeist/teamgeist/blobs/master/tp_classes.py Basically.. you want a Channel, then do : class Channel (BaseChannel): you want to listen to the 'HandleChannel' dbus signal, then do : method HandleChannel ( ... ) that's it.. the base classes will look for the method names, and automatically do introspection on the objects and connect the signals, or send the dbus methods when you call a local method, etc... so, actually dbus + python.. I don't mind that dependency that much... -- Boris 'billiob' Faure -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Op maandag 5 juni 2006 22:07, schreef Philippe Khalaf: Hi, Well after seeing that long thread about languages, it kinda feels like there is no solution but to keep the GUI in tcl/tk. We will never agree on a new language, we already know tcl/tk, and we have a whole lot of GUI code already written in TCL/TK. I think there is another solution. XML2GUI is probably going to work (I am working hard on that) so that would mean a Gtk-based engine written in C and the actual gui written in XML. If we want to keep the 'logic' part in tcl/tk, we'd just need a connector to pass on the events. Information about the XML2GUI plan will be in the wiki when there is really something to tell (i.e. when there is a beginning of a real design instead of just a few experiments). The back-end (connection manager) could be written in anything as it doesn't really matter or doesn't even need to be an amsn only project. It can be started by someone else, and contributed to by us, or vice versa. In any case there are several outsiders to aMSN interested in such a project so it's not an issue. I agree to this. Regards, Philippe On Wed, 24 May 2006 20:32:10 -0400 Philippe Khalaf [EMAIL PROTECTED] wrote: Hi, I have been reading the mailing list and I gather that people are getting rather bored. But the main problem is that everyone seems to be busy. In any case, I have sent a similar email before but I am doing it again. Now Telepathy is at a different stage of it's life. It's actually working now and a project like aMSN2 can be started. In case you guys don't know it, Telepathy is getting big and it will soon become an integral part of the Gnome desktop, and hopefully KDE. If aMSN2 was to be started, it would consist of 2 main projects : - An MSN connection manager for Telepathy (a kind of protocol plugin) : This is where the aMSN people can be very helpful since you all have a rather good knowledge of the MSN protocol and can write this easily. This of course can be written in a different language than TCL. Any language that has DBUS bindings will do (C/GLib, C++, QT Objects, python, etc). - An aMSN2 GUI. Brand new GUI. The cool thing about aMSN is it's feature list. The aMSN devels have come up with cool features that are actually useful and not just stupid little gadgets. This can be transported into a brand new UI that uses Telepathy, and it can be written with another toolkit like GTK or QT. A new UI can be started immediately using the Jabber connection manager (called gabble) while the MSN connection manager is being worked on. In other words, aMSN2 would be a completely different project, but I believe aMSN is what it is not because of tcl/tk and not because of it's pretty code :P but because of the features and feel that it has, and that is a direct reflection of the community that works on it. If the feel of aMSN can be maintained, it doesn't matter what back-end it uses, or what toolkit it's written in. It can only look better anyways :) There are a lot of positive things about moving on to Telepathy : - Put some life back into the project. - New languages and new skills to learn. I'm talking C, C++, GLib, GTK, QT, D-BUS or anything else we want. - New toolkit, new look. - Solid and well designed framework. - Getting in sync with the future. Telepathy is big now. We have a GUADEC main talk, we got 2 summer of code entries and we financially support the project. Any UIs or projects associated with it will also be big (aMSN is already big and can take it's popularity with it). - Transparent support for other protocols (jabber, oscar, etc). - Full audio/video support with Farsight. I will let you come up with any drawbacks or bad things about it. If anyone is interested in taking this direction. Tell me right now! I can definitely help out with managing such a project and designing anything that needs to be designed. Obviously I am very close to Telepathy and can help with anything in that regards as well. You guys want a spark here is your chance. Take it or leave it the Telepathy train is taking passengers but isn't slowing down! Regards, Philippe --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Tue, 06 Jun 2006 13:24:24 -0400, Harry Vennik [EMAIL PROTECTED] wrote: Op maandag 5 juni 2006 22:07, schreef Philippe Khalaf: Hi, Well after seeing that long thread about languages, it kinda feels like there is no solution but to keep the GUI in tcl/tk. We will never agree on a new language, we already know tcl/tk, and we have a whole lot of GUI code already written in TCL/TK. I think there is another solution. XML2GUI is probably going to work (I am working hard on that) so that would mean a Gtk-based engine written in C and the actual gui written in XML. If we want to keep the 'logic' part in tcl/tk, we'd just need a connector to pass on the events. Information about the XML2GUI plan will be in the wiki when there is really something to tell (i.e. when there is a beginning of a real design instead of just a few experiments). very nice.. I hope you didn't waste your precious time and you looked at the tcl/tk wiki for some already existing implementations of xml2gui. Do you also have the thread of when talking about xml2gui, maybe you'll find something there that is of interest. anyways, thanx for not sleeping during this time where everyone seems to be taking holidays... The back-end (connection manager) could be written in anything as it doesn't really matter or doesn't even need to be an amsn only project. It can be started by someone else, and contributed to by us, or vice versa. In any case there are several outsiders to aMSN interested in such a project so it's not an issue. I agree to this. I agree too, but I still think C is good :P j/k no more flaming. Regards, Philippe On Wed, 24 May 2006 20:32:10 -0400 Philippe Khalaf [EMAIL PROTECTED] wrote: Hi, I have been reading the mailing list and I gather that people are getting rather bored. But the main problem is that everyone seems to be busy. In any case, I have sent a similar email before but I am doing it again. Now Telepathy is at a different stage of it's life. It's actually working now and a project like aMSN2 can be started. In case you guys don't know it, Telepathy is getting big and it will soon become an integral part of the Gnome desktop, and hopefully KDE. If aMSN2 was to be started, it would consist of 2 main projects : - An MSN connection manager for Telepathy (a kind of protocol plugin) : This is where the aMSN people can be very helpful since you all have a rather good knowledge of the MSN protocol and can write this easily. This of course can be written in a different language than TCL. Any language that has DBUS bindings will do (C/GLib, C++, QT Objects, python, etc). - An aMSN2 GUI. Brand new GUI. The cool thing about aMSN is it's feature list. The aMSN devels have come up with cool features that are actually useful and not just stupid little gadgets. This can be transported into a brand new UI that uses Telepathy, and it can be written with another toolkit like GTK or QT. A new UI can be started immediately using the Jabber connection manager (called gabble) while the MSN connection manager is being worked on. In other words, aMSN2 would be a completely different project, but I believe aMSN is what it is not because of tcl/tk and not because of it's pretty code :P but because of the features and feel that it has, and that is a direct reflection of the community that works on it. If the feel of aMSN can be maintained, it doesn't matter what back-end it uses, or what toolkit it's written in. It can only look better anyways :) There are a lot of positive things about moving on to Telepathy : - Put some life back into the project. - New languages and new skills to learn. I'm talking C, C++, GLib, GTK, QT, D-BUS or anything else we want. - New toolkit, new look. - Solid and well designed framework. - Getting in sync with the future. Telepathy is big now. We have a GUADEC main talk, we got 2 summer of code entries and we financially support the project. Any UIs or projects associated with it will also be big (aMSN is already big and can take it's popularity with it). - Transparent support for other protocols (jabber, oscar, etc). - Full audio/video support with Farsight. I will let you come up with any drawbacks or bad things about it. If anyone is interested in taking this direction. Tell me right now! I can definitely help out with managing such a project and designing anything that needs to be designed. Obviously I am very close to Telepathy and can help with anything in that regards as well. You guys want a spark here is your chance. Take it or leave it the Telepathy train is taking passengers but isn't slowing down! Regards, Philippe --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red
Re: [Amsn-devel] aMSN2 and Telepathy
Hi, Well after seeing that long thread about languages, it kinda feels like there is no solution but to keep the GUI in tcl/tk. We will never agree on a new language, we already know tcl/tk, and we have a whole lot of GUI code already written in TCL/TK. The back-end (connection manager) could be written in anything as it doesn't really matter or doesn't even need to be an amsn only project. It can be started by someone else, and contributed to by us, or vice versa. In any case there are several outsiders to aMSN interested in such a project so it's not an issue. Regards, Philippe On Wed, 24 May 2006 20:32:10 -0400 Philippe Khalaf [EMAIL PROTECTED] wrote: Hi, I have been reading the mailing list and I gather that people are getting rather bored. But the main problem is that everyone seems to be busy. In any case, I have sent a similar email before but I am doing it again. Now Telepathy is at a different stage of it's life. It's actually working now and a project like aMSN2 can be started. In case you guys don't know it, Telepathy is getting big and it will soon become an integral part of the Gnome desktop, and hopefully KDE. If aMSN2 was to be started, it would consist of 2 main projects : - An MSN connection manager for Telepathy (a kind of protocol plugin) : This is where the aMSN people can be very helpful since you all have a rather good knowledge of the MSN protocol and can write this easily. This of course can be written in a different language than TCL. Any language that has DBUS bindings will do (C/GLib, C++, QT Objects, python, etc). - An aMSN2 GUI. Brand new GUI. The cool thing about aMSN is it's feature list. The aMSN devels have come up with cool features that are actually useful and not just stupid little gadgets. This can be transported into a brand new UI that uses Telepathy, and it can be written with another toolkit like GTK or QT. A new UI can be started immediately using the Jabber connection manager (called gabble) while the MSN connection manager is being worked on. In other words, aMSN2 would be a completely different project, but I believe aMSN is what it is not because of tcl/tk and not because of it's pretty code :P but because of the features and feel that it has, and that is a direct reflection of the community that works on it. If the feel of aMSN can be maintained, it doesn't matter what back-end it uses, or what toolkit it's written in. It can only look better anyways :) There are a lot of positive things about moving on to Telepathy : - Put some life back into the project. - New languages and new skills to learn. I'm talking C, C++, GLib, GTK, QT, D-BUS or anything else we want. - New toolkit, new look. - Solid and well designed framework. - Getting in sync with the future. Telepathy is big now. We have a GUADEC main talk, we got 2 summer of code entries and we financially support the project. Any UIs or projects associated with it will also be big (aMSN is already big and can take it's popularity with it). - Transparent support for other protocols (jabber, oscar, etc). - Full audio/video support with Farsight. I will let you come up with any drawbacks or bad things about it. If anyone is interested in taking this direction. Tell me right now! I can definitely help out with managing such a project and designing anything that needs to be designed. Obviously I am very close to Telepathy and can help with anything in that regards as well. You guys want a spark here is your chance. Take it or leave it the Telepathy train is taking passengers but isn't slowing down! Regards, Philippe --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Thu, 2006-06-01 at 22:45 +0200, Harry Vennik wrote: Yes, you may be right, be we also need to think about what we are going to do ourselves. For that I think there is just: - Tcl because we use that now, and we all know it - C because it is the best programming language that compiles to native code And if I say Visual Basic is the best without backing that up, who of us would be right? Yes you say is the best that compiles to native code, but you don't say why that is a good thing, or why it IS the best. I prefer C. That is a much better sentence then the one above. I've always disliked interpreted languages because of their lack of speed. And Youness: Java is faster than C for processing Benchmarks please :-P Harry P.S. reading back what i wrote it can be interpreted as a bit harsh, but it is not meant that way. I just mean to say everybody has a language of choice, and you have a high risk of saying that language is the best. When you do so please add in my opinion or a link to a benchmark (not that benchmarks mean a lot, since you can probably find a benchmark for any case you want) signature.asc Description: This is a digitally signed message part ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
If you want a fast language, use OCaml : (http://caml.inria.fr/index.en.html) I code with this language at school, and it's very funny and pleasant. The code is also quite small; but it's not an easy language as python or tcl. It can be compiled in native code or in bytecode. Well, stop talking about which is the best language. There is already a project for an msn client written in python : ask Ole Andre Vadla Ravnas. 2006/6/2, Sander Hoentjen [EMAIL PROTECTED]: On Thu, 2006-06-01 at 22:45 +0200, Harry Vennik wrote: Yes, you may be right, be we also need to think about what we are going to do ourselves. For that I think there is just: - Tcl because we use that now, and we all know it - C because it is the best programming language that compiles to native code And if I say Visual Basic is the best without backing that up, who of us would be right? Yes you say is the best that compiles to native code, but you don't say why that is a good thing, or why it IS the best. I prefer C. That is a much better sentence then the one above. I've always disliked interpreted languages because of their lack of speed. And Youness: Java is faster than C for processing Benchmarks please :-P Harry P.S. reading back what i wrote it can be interpreted as a bit harsh, but it is not meant that way. I just mean to say everybody has a language of choice, and you have a high risk of saying that language is the best. When you do so please add in my opinion or a link to a benchmark (not that benchmarks mean a lot, since you can probably find a benchmark for any case you want) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEf9q7ATrECtEe6c8RAlWZAKDry0IhQDH96VezgwGyE9X9uUopsgCg0Fuf SRhwf8XJevmgAdbmpHPCYDo= =qldQ -END PGP SIGNATURE- ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- Boris FAURE (aka billiob) mail, msn : [EMAIL PROTECTED] No trees were killed in the sending of this message. However, a large number of electrons were terribly agitated. ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
STOP TALKING ABOUT NEW LANGUAGES... + Ocalm is crap, I don't know about the language, but I remember when I downloaded an ocalm program, it took me a day to compile it, compiler is crap, dependencies are crap, etc... don't know if it changes though... and anyways, we want to avoid new languages, right ? we want to keep the same team, not fire all devels and hire new ones who already know the language... if we go with a language that we don't all nkow well already, we'll end up with crap code, look at everyone's code when they first began.. look at ccmsn code, look at my own first code in amsn, it's all crap. We need experience in the languages... KKRT On Fri, 02 Jun 2006 11:42:22 -0400, Boris Faure (aka billiob) [EMAIL PROTECTED] wrote: If you want a fast language, use OCaml : (http://caml.inria.fr/index.en.html) I code with this language at school, and it's very funny and pleasant. The code is also quite small; but it's not an easy language as python or tcl. It can be compiled in native code or in bytecode. Well, stop talking about which is the best language. There is already a project for an msn client written in python : ask Ole Andre Vadla Ravnas. 2006/6/2, Sander Hoentjen [EMAIL PROTECTED]: On Thu, 2006-06-01 at 22:45 +0200, Harry Vennik wrote: Yes, you may be right, be we also need to think about what we are going to do ourselves. For that I think there is just: - Tcl because we use that now, and we all know it - C because it is the best programming language that compiles to native code And if I say Visual Basic is the best without backing that up, who of us would be right? Yes you say is the best that compiles to native code, but you don't say why that is a good thing, or why it IS the best. I prefer C. That is a much better sentence then the one above. I've always disliked interpreted languages because of their lack of speed. And Youness: Java is faster than C for processing Benchmarks please :-P Harry P.S. reading back what i wrote it can be interpreted as a bit harsh, but it is not meant that way. I just mean to say everybody has a language of choice, and you have a high risk of saying that language is the best. When you do so please add in my opinion or a link to a benchmark (not that benchmarks mean a lot, since you can probably find a benchmark for any case you want) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEf9q7ATrECtEe6c8RAlWZAKDry0IhQDH96VezgwGyE9X9uUopsgCg0Fuf SRhwf8XJevmgAdbmpHPCYDo= =qldQ -END PGP SIGNATURE- ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
i just love how you do kkrt, when you don't know something you first hate it and then consider it :)IMHO :- python's indentation is strange but force devs to code with the same style- it would be pointless to move from an interpreted language to another interpreted language (maybe python's case is specific here, because of the .pyc files but i'm shure other interpreted language offers this feature) - i don't feel like i want to download java's jre to use amsn- if you switch from tcl to whatever you like, drop tk to : most people have it installed because they are using amsn (but that would also mean to forget about skinks, tuff decision) my 2 cents...-- Maxime VERZIER (www.billets-orientes.com / www.verzier.info) ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
- Original Message - From: Youness Alaoui [EMAIL PROTECTED] The GUI could be a mix between different languages, I like Tk for its ease of use, Qt is too crap to program and gnome, I don't know.. but usually any GUI written in C/C++ is difficult to program (afaik, I could be wrong). I don't want to put java in the debate because java's Achilles' heel is the GUI (slow)... the new CL is event driven, and we have the dbus extension for tcl we can use... now that we got the 0.96 in a new branch, I think we're going to be more active! Hi :) First I must say I'm not spamming nor flaming as someone thought for a while on the forum :P Said this, seriously, if you wish (or just would like to consider) to change programming language and gui toolkit I think you may want to go for python; python is a well supported, well tested dynamic language, featuring good speed and nice gtk bindings (pygtk) e.g.: gajim is a gtk + python jabber client once again I don't love much its syntax (indentation has semantic? why on Earth?? :P ) but it's not that bad. :P Moreover, python is not merely interpreted but its compiled into bytecode on the fly before running (once it has been compiled the first time, if source files didn't change, then it won't be compiled anymore, but the previously generated *.pyc files will be run) so it (is supposed to :P ) gain points in speed. Many tools in Gnome are coded using python (for instance panel widgets, plugins for many apps, like epiphany), many graphic frontends (if I remember even synaptic is in python! and many ubuntu tools are, too, e.g. the update-manager, and many more I can't remember now) making it a good choice. As for the toolkit war, gtk features cross-integration between platforms/DEs over qt (and sure over tk). In fact, while qt works nicely under windows and when working under kde, it feels alien in a gnome environment, while installing gtk-qt engine for gtk+ widgets will make your gtk application look as native qt apps in your kde, looking nice as always in gnome, and still it will look window-ish on windows http://gtk-wimp.sourceforge.net/ ). I'm not sure about OS X. As far as I know gtk programming is not far from tk (but I don't know so much of both), you pack your widgets and so on... ( pygtk example: http://www.pygtk.org/pygtk2tutorial/sec-PackingDemonstrationProgram.html ) here's the hello world: http://www.pygtk.org/pygtk2tutorial/ch-GettingStarted.html#sec-HelloWorld there are more lines of comment than real lines of code :P Let's then say I'm NOT a python programmer, nor I'm advertising python, nor I'm trying to sell you anything :P These are just suggestions... no! even less! just *thoughts*, so take them for what they are ;) as I said on the forum, if *I* had to think about starting a new project these are the considerations *I* would make, so I'm telling you this so that (maybe) you could find them useful :) bye :) ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? should we drop the .tcl files completly ? KaKaRoTo On Thu, 01 Jun 2006 14:05:28 -0400, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] The GUI could be a mix between different languages, I like Tk for its ease of use, Qt is too crap to program and gnome, I don't know.. but usually any GUI written in C/C++ is difficult to program (afaik, I could be wrong). I don't want to put java in the debate because java's Achilles' heel is the GUI (slow)... the new CL is event driven, and we have the dbus extension for tcl we can use... now that we got the 0.96 in a new branch, I think we're going to be more active! Hi :) First I must say I'm not spamming nor flaming as someone thought for a while on the forum :P Said this, seriously, if you wish (or just would like to consider) to change programming language and gui toolkit I think you may want to go for python; python is a well supported, well tested dynamic language, featuring good speed and nice gtk bindings (pygtk) e.g.: gajim is a gtk + python jabber client once again I don't love much its syntax (indentation has semantic? why on Earth?? :P ) but it's not that bad. :P Moreover, python is not merely interpreted but its compiled into bytecode on the fly before running (once it has been compiled the first time, if source files didn't change, then it won't be compiled anymore, but the previously generated *.pyc files will be run) so it (is supposed to :P ) gain points in speed. Many tools in Gnome are coded using python (for instance panel widgets, plugins for many apps, like epiphany), many graphic frontends (if I remember even synaptic is in python! and many ubuntu tools are, too, e.g. the update-manager, and many more I can't remember now) making it a good choice. As for the toolkit war, gtk features cross-integration between platforms/DEs over qt (and sure over tk). In fact, while qt works nicely under windows and when working under kde, it feels alien in a gnome environment, while installing gtk-qt engine for gtk+ widgets will make your gtk application look as native qt apps in your kde, looking nice as always in gnome, and still it will look window-ish on windows http://gtk-wimp.sourceforge.net/ ). I'm not sure about OS X. As far as I know gtk programming is not far from tk (but I don't know so much of both), you pack your widgets and so on... ( pygtk example: http://www.pygtk.org/pygtk2tutorial/sec-PackingDemonstrationProgram.html ) here's the hello world: http://www.pygtk.org/pygtk2tutorial/ch-GettingStarted.html#sec-HelloWorld there are more lines of comment than real lines of code :P Let's then say I'm NOT a python programmer, nor I'm advertising python, nor I'm trying to sell you anything :P These are just suggestions... no! even less! just *thoughts*, so take them for what they are ;) as I said on the forum, if *I* had to think about starting a new project these are the considerations *I* would make, so I'm telling you this so that (maybe) you could find them useful :) bye :) ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
- Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/ :D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Chameleon... ^o) if we're going to use Tk, I think we should use tile from the very start... BANG! p.s: that was a shot... KKRT On Thu, 01 Jun 2006 14:56:50 -0400, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/ :D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
- Original Message - From: Youness Alaoui [EMAIL PROTECTED] Chameleon... ^o) if we're going to use Tk, I think we should use tile from the very start... BANG! ouch! :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)...By the way, is telepathy suported on windows?On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote:- Original Message -From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it fromthe point of view of ease of use, more than beauty itself (even if I agree alittle with you :)).really, it doesn't look that bad ;)And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI.As I said, gtk doesn't look that bad in every programming language (gtk isC). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ?shoot me: I don't like how tk looks :Dyou have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ?not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/ :Dok, beat me :P ___Amsn-devel mailing listAmsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel-- Bruno Costa:wq ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
I think you misread the mail... He says that if we do a backend for Telepathy, he will create its own GUI with Java... He doesn't ask anything... (Maybe he asks for the backend :p) Phil Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit : Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
well, he's not asking, but he says I'm willing to, which means, he wants to do it, which means he wants his code to be used... I wouldn't want to have download amsn, then download a frontend for it, it's not like svn, you download the svn client, then download tortoisesvn or rapidsvn for a frontend... it should be a single app, backend/frontend, it should all be transparent to the user (as well as the language used by each components). If he does what he said, for himself, I'm sure he'd like to make it available for everyone to use.. then other's would like to know hey, how did he do it.. ouhhh, I can use your backend and have my own GUI ? then we'll get 10s of frontends, and lots of requests on how do you get the notification for this.. my gui doesn't want to update on status change... and there, you add a 'library support' to the 'client support'... amsn is an msn clone/client, not an msn library + frontend... that's what I meant .. or mean... KKRT On Thu, 01 Jun 2006 16:17:27 -0400, Philippe Valembois - Phil [EMAIL PROTECTED] wrote: I think you misread the mail... He says that if we do a backend for Telepathy, he will create its own GUI with Java... He doesn't ask anything... (Maybe he asks for the backend :p) Phil Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit : Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P
Re: [Amsn-devel] aMSN2 and Telepathy
I understand your point, but what I said was that I would implement a java frontend, something like a hobby project, a proof of concept, to show that good swing programming isn't that slow, but nothing like the real fully featured amsn :D On 6/1/06, Youness Alaoui [EMAIL PROTECTED] wrote: Why are people asking for what they like, and not thinking about what isright...Yes, java development is really nice and fast! but java still has a lot ofdisadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. andyes, java is fast, it's even faster than C (really!) for processing, butthe whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :pI'm trying to think about what would be the most beneficial for all of us,as developers and for our users. So java is not the perfect solution (butnot out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop beinmotivated. Don't know about you python geeks, but in my case, I'm narrowminded and I don't want to know what python is :P (looks crappy to me) KKRTOn Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel--KaKaRoTo___Amsn-devel mailing list Amsn-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/amsn-devel-- Bruno Costa :wq ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NoWhereMan wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] Chameleon... ^o) if we're going to use Tk, I think we should use tile from the very start... BANG! ouch! :P About choosing a language ... I think we should first consider what are the languages where a telepathy library is implemented. My point of view is that telepathy use dbus a lot, so we also need a language with a dbus library. http://telepathy.freedesktop.org/wiki/ With those characterisitcs we'll save a lot of boring development time and will be able to focus on the fun parts :) My point of view ... that may not be a good one :) GrdScarabe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEf1CYPmfsnt4Id3wRAs1rAKCgVKhkldREQffQPK8nLHvABYxTBwCdFpdo +yiqigtwv5hSt+eFPXupw7k= =/CDl -END PGP SIGNATURE- ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Yes, you may be right, be we also need to think about what we are going to do ourselves. For that I think there is just: - Tcl because we use that now, and we all know it - C because it is the best programming language that compiles to native code I prefer C. I've always disliked interpreted languages because of their lack of speed. And Youness: Java is faster than C for processing Benchmarks please :-P Harry Op donderdag 1 juni 2006 22:17, schreef Philippe Valembois - Phil: I think you misread the mail... He says that if we do a backend for Telepathy, he will create its own GUI with Java... He doesn't ask anything... (Maybe he asks for the backend :p) Phil Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit : Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
Benchmarks and articles here ya go! (now I'll be killed)http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.javalobby.org/articles/swing_slow/index.jspJava Hotspot: http://en.wikipedia.org/wiki/HotSpotAdaptive optimization: http://en.wikipedia.org/wiki/Adaptive_optimizationhttp://www.javaworld.com/jw-02-1998/jw-02-jperf.html Note that these articles are relatively old, java today is even faster.Of course, I understand that a VM and the OO concepts introduces some overhead, but tcl, ruby, python, perl, c# all these languages are slower or as fast as java, but noone seems to be saying it all time :) On 6/1/06, Harry Vennik [EMAIL PROTECTED] wrote: Yes, you may be right, be we also need to think about what we are going to doourselves. For that I think there is just:- Tcl because we use that now, and we all know it- C because it is the best programming language that compiles to native code I prefer C.I've always disliked interpreted languages because of their lack of speed.And Youness: Java is faster than C for processing Benchmarks please :-PHarryOp donderdag 1 juni 2006 22:17, schreef Philippe Valembois - Phil: I think you misread the mail... He says that if we do a backend for Telepathy, he will create its own GUI with Java... He doesn't ask anything... (Maybe he asks for the backend :p) Phil Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit: Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but Ijust hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a newlanguage, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language...if we could get the hell out of tcl/Tk (or any interpretedlanguage), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff...we could drop the whole interpreter thing, the Data/ structurescould be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API toaccess those...and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe you know it):
Re: [Amsn-devel] aMSN2 and Telepathy
On 6/1/06, Philippe Valembois - Phil [EMAIL PROTECTED] wrote: I think you misread the mail...He says that if we do a backend for Telepathy, he will create its own GUI withJava... He doesn't ask anything... (Maybe he asks for the backend :p)PhilThanks Phil! Youness often misreads my e-mails, I think he doesn't like me :(Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit: Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED]python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but Inever even felt the need to look at what the code looks like, I just hateit from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :Dmoreover, the main reason why we'd avoid python (if everyone agrees withme), is that we're tcl/tk programmers here.. learning a new language, nothanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to createGUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (whoever invented this quote???), which is why we want to stick to Tk for ourGUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrongway in some stuff... we could drop the whole interpreter thing, the Data/ structures could beheld in C structure (don't talk about C++ because of ABI, but C++ is thenicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library...no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh!should we drop the .tcl files completly ? not to be repetitive (maybe you know it): http://tcl-gtk.sourceforge.net/:D ok, beat me :P ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel___Amsn-devel mailing list Amsn-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/amsn-devel -- Bruno Costa:wq ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Thu, 01 Jun 2006 16:26:13 -0400, Bruno Costa [EMAIL PROTECTED] wrote: On 6/1/06, Philippe Valembois - Phil [EMAIL PROTECTED] wrote: I think you misread the mail... He says that if we do a backend for Telepathy, he will create its own GUI with Java... He doesn't ask anything... (Maybe he asks for the backend :p) Phil Thanks Phil! Youness often misreads my e-mails, I think he doesn't like me :( ll, n, not true, not true.. I don't even know who you are.. I even thought it was your first post :P actually, I never read the sender's name, some of you are in my 'Contacts', and the email appears with a different icon for emails coming from my contacts (vivia, sander, karol, alvaro, phil, Jerome...), in which case, I see who sent it, and take into consideration the person who sent it (knowing that what person X said will have more 'value' than person Y, not discimination, but for example, vivia giving advice about TkCximage means less than Phil's word, because vivia knows (practicly) nothing about Cximage while Phil worked with it intensively) so it's nothing personal, ok? I know you said it in an ironic/joking way, but let's just make sure there is no misunderstanding :) KaKaRoTo Le Thursday 01 June 2006 21:51, Youness Alaoui a écrit: Why are people asking for what they like, and not thinking about what is right... Yes, java development is really nice and fast! but java still has a lot of disadvantages for such a project, first, people hate it (:P), the JVM must be installed and is huge to download, so it's sad for dialup people. and yes, java is fast, it's even faster than C (really!) for processing, but the whole GUI part of Java is SLOW AS HELL, and yes, it is... also, please don't talk about that mercury crap :p I'm trying to think about what would be the most beneficial for all of us, as developers and for our users. So java is not the perfect solution (but not out of the way yet), and python/perl, please... we don't need any more integration/training phase.. + we need people to work, not stop bein motivated. Don't know about you python geeks, but in my case, I'm narrow minded and I don't want to know what python is :P (looks crappy to me) KKRT On Thu, 01 Jun 2006 15:34:41 -0400, Bruno Costa [EMAIL PROTECTED] wrote: I'm not an amsn developer (please, don't kill me), but if you guys are going to develop a MSN backend for telepathy I'm willing to implement a java/swing frontend! (and no, java isn't slow as hell, and yes, mercury is a bugged piece of crap) :D Apart from java I prefer python (maybe with pygtk)... By the way, is telepathy suported on windows? On 6/1/06, NoWhereMan [EMAIL PROTECTED] wrote: - Original Message - From: Youness Alaoui [EMAIL PROTECTED] python, NO, perl, NO... I know these languages are popular, but I just hate the syntax, and especially python, I heard so much about it, but I never even felt the need to look at what the code looks like, I just hate it from the start... Neither I like it so much, but maybe you have to think about it from the point of view of ease of use, more than beauty itself (even if I agree a little with you :)). really, it doesn't look that bad ;) And btw, you said you didn't like tcl as well :D moreover, the main reason why we'd avoid python (if everyone agrees with me), is that we're tcl/tk programmers here.. learning a new language, no thanks... C code is for those who knows C code, and there are a few in here, and it's still the standard programming language... if we could get the hell out of tcl/Tk (or any interpreted language), I would 100% do it, the only problem with C code is that it's hard to create GUIs with it (I think, anyways, I'm still under the trauma of my Qt course...), while in Tk, it's as easy as stealing a cnady from a kid (who ever invented this quote???), which is why we want to stick to Tk for our GUI. As I said, gtk doesn't look that bad in every programming language (gtk is C). pygtk is just a wrapper What you have said though made me realize that we might be going the wrong way in some stuff... we could drop the whole interpreter thing, the Data/ structures could be held in C structure (don't talk about C++ because of ABI, but C++ is the nicest way to do it, I know!), and we could have a nice API to access those... and the GUI.. we could still use Tk inside C code with the Tk library... no ? shoot me: I don't like how tk looks :D you have to compile yourself tcl/tk 8.5 just to have antialiased fonts... d'uh! should we drop the .tcl files completly ? not to be repetitive (maybe
Re: [Amsn-devel] aMSN2 and Telepathy
On 5/26/06, Youness Alaoui [EMAIL PROTECTED] wrote: On Fri, 26 May 2006 12:53:37 -0400, [EMAIL PROTECTED] wrote: On 5/25/06, Youness Alaoui [EMAIL PROTECTED] wrote: lol @ your last sentence, nice though :) You know how I feel about that, so you can count me in, as soon as I get some time, I'll be doing some stuff.. right now I'm rewriting part of the new CL that Karel wrote, making it even more modular and easy to use (his current design was good, but it depended on an option available only in tcl 8.5, so now I thought of another possible design/implementation and I'm doing it, using a lot of what was already there). so, you know about the wiki right, there's an amsn2 page in there with what we first talked about, any ideas should go there. The GUI could be a mix between different languages, I like Tk for its ease of use, Qt is too crap to program and gnome, I don't know.. but usually any GUI written in C/C++ is difficult to program (afaik, I could be wrong). I don't want to put java in the debate because java's Achilles' heel is the GUI (slow)... the new CL is event driven, and we have the dbus extension for tcl we can use... now that we got the 0.96 in a new branch, I think we're going to be more active! I suggest we branch into 2_0 for farsight/telepathy stuff... the xml2gui project might be useless as it seems a similar thing already exists and I think Tom would want to put TkHtml in... Damn right :) so I think tcl/tk megawidgets with snit (like the clgui.tcl) and tkhtml for some fancy stuff like bg images, and we got ourself a nice GUI... then we'll move the events from protocol.tcl into telepathy2amsncore.c The contact list can be done in tkhtml too :) Skiable :D KKRT Tom changed from a nice guy with good artistic skills, into a skin freak... watch out everyone! he might skin you alive for his new project :P I have my eye on yours ;) -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
On Fri, 26 May 2006 12:53:37 -0400, [EMAIL PROTECTED] wrote: On 5/25/06, Youness Alaoui [EMAIL PROTECTED] wrote: lol @ your last sentence, nice though :) You know how I feel about that, so you can count me in, as soon as I get some time, I'll be doing some stuff.. right now I'm rewriting part of the new CL that Karel wrote, making it even more modular and easy to use (his current design was good, but it depended on an option available only in tcl 8.5, so now I thought of another possible design/implementation and I'm doing it, using a lot of what was already there). so, you know about the wiki right, there's an amsn2 page in there with what we first talked about, any ideas should go there. The GUI could be a mix between different languages, I like Tk for its ease of use, Qt is too crap to program and gnome, I don't know.. but usually any GUI written in C/C++ is difficult to program (afaik, I could be wrong). I don't want to put java in the debate because java's Achilles' heel is the GUI (slow)... the new CL is event driven, and we have the dbus extension for tcl we can use... now that we got the 0.96 in a new branch, I think we're going to be more active! I suggest we branch into 2_0 for farsight/telepathy stuff... the xml2gui project might be useless as it seems a similar thing already exists and I think Tom would want to put TkHtml in... Damn right :) so I think tcl/tk megawidgets with snit (like the clgui.tcl) and tkhtml for some fancy stuff like bg images, and we got ourself a nice GUI... then we'll move the events from protocol.tcl into telepathy2amsncore.c The contact list can be done in tkhtml too :) Skiable :D KKRT Tom changed from a nice guy with good artistic skills, into a skin freak... watch out everyone! he might skin you alive for his new project :P -- KaKaRoTo ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
Re: [Amsn-devel] aMSN2 and Telepathy
lol @ your last sentence, nice though :) You know how I feel about that, so you can count me in, as soon as I get some time, I'll be doing some stuff.. right now I'm rewriting part of the new CL that Karel wrote, making it even more modular and easy to use (his current design was good, but it depended on an option available only in tcl 8.5, so now I thought of another possible design/implementation and I'm doing it, using a lot of what was already there). so, you know about the wiki right, there's an amsn2 page in there with what we first talked about, any ideas should go there. The GUI could be a mix between different languages, I like Tk for its ease of use, Qt is too crap to program and gnome, I don't know.. but usually any GUI written in C/C++ is difficult to program (afaik, I could be wrong). I don't want to put java in the debate because java's Achilles' heel is the GUI (slow)... the new CL is event driven, and we have the dbus extension for tcl we can use... now that we got the 0.96 in a new branch, I think we're going to be more active! I suggest we branch into 2_0 for farsight/telepathy stuff... the xml2gui project might be useless as it seems a similar thing already exists and I think Tom would want to put TkHtml in... so I think tcl/tk megawidgets with snit (like the clgui.tcl) and tkhtml for some fancy stuff like bg images, and we got ourself a nice GUI... then we'll move the events from protocol.tcl into telepathy2amsncore.c KKRT On Wed, 24 May 2006 20:32:10 -0400, Philippe Khalaf [EMAIL PROTECTED] wrote: Hi, I have been reading the mailing list and I gather that people are getting rather bored. But the main problem is that everyone seems to be busy. In any case, I have sent a similar email before but I am doing it again. Now Telepathy is at a different stage of it's life. It's actually working now and a project like aMSN2 can be started. In case you guys don't know it, Telepathy is getting big and it will soon become an integral part of the Gnome desktop, and hopefully KDE. If aMSN2 was to be started, it would consist of 2 main projects : - An MSN connection manager for Telepathy (a kind of protocol plugin) : This is where the aMSN people can be very helpful since you all have a rather good knowledge of the MSN protocol and can write this easily. This of course can be written in a different language than TCL. Any language that has DBUS bindings will do (C/GLib, C++, QT Objects, python, etc). - An aMSN2 GUI. Brand new GUI. The cool thing about aMSN is it's feature list. The aMSN devels have come up with cool features that are actually useful and not just stupid little gadgets. This can be transported into a brand new UI that uses Telepathy, and it can be written with another toolkit like GTK or QT. A new UI can be started immediately using the Jabber connection manager (called gabble) while the MSN connection manager is being worked on. In other words, aMSN2 would be a completely different project, but I believe aMSN is what it is not because of tcl/tk and not because of it's pretty code :P but because of the features and feel that it has, and that is a direct reflection of the community that works on it. If the feel of aMSN can be maintained, it doesn't matter what back-end it uses, or what toolkit it's written in. It can only look better anyways :) There are a lot of positive things about moving on to Telepathy : - Put some life back into the project. - New languages and new skills to learn. I'm talking C, C++, GLib, GTK, QT, D-BUS or anything else we want. - New toolkit, new look. - Solid and well designed framework. - Getting in sync with the future. Telepathy is big now. We have a GUADEC main talk, we got 2 summer of code entries and we financially support the project. Any UIs or projects associated with it will also be big (aMSN is already big and can take it's popularity with it). - Transparent support for other protocols (jabber, oscar, etc). - Full audio/video support with Farsight. I will let you come up with any drawbacks or bad things about it. If anyone is interested in taking this direction. Tell me right now! I can definitely help out with managing such a project and designing anything that needs to be designed. Obviously I am very close to Telepathy and can help with anything in that regards as well. You guys want a spark here is your chance. Take it or leave it the Telepathy train is taking passengers but isn't slowing down! Regards, Philippe --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net
