hi,
as phil said, we were going to talk about the rewrite, design, modularity, etc.. and it ended up with.. let me see... ALL posts talking about the language to use!!!!!! we DO NOT want this, and I will split this thread to keep it clean.
As phil also said, it will be modular and you can put the GUI you want, if you want a C++/QT GUI then write it the way you want and integrate it with tcl because the core will stay Tcl! if you want a ml/xml/javascript/whatever GUI, then do it, and integrate it with the core.. all you'll need is :
1 - catch/send events from/to Tcl
2 - access the data storage object from Tcl
I think Auria words are wise, so listen up!
Maybe it's time to learn C++?
don't worry v0n0, I'm a C/C++/Java expert, Phil is a C/C++ expert, don't know about Java but I think he uses it too, we have ObjCalm experts, we all have many talents, and C/C++ is the language that we also know, but not everyone...
For aMSN, did you know that EVERYONE in the team started without knowing shit about the language? nothing, just copy pasting and adapting old code, or fixing bugs until you learn the language.. it takes a few hours to manage to learn the language, only by looking at the code.. but for C/C++ you won't learn every bit of the language just like that... many of us don't want to learn the language... but that's stilll not the reason we don't want to use it...
the ABI!!! it keeps changing.. we have one module in amsn (utils/TkCximage) which is written in C++ and we're hoping to get rid of it, because although it's nice on windows and mac, it's hell for linux users! the ABI changes every couple of months, everyone needs to have the same libraries or else it won't work, we stopped doing all those distro releases partly because of that, it never worked, everyone has a different system, etc... C++ is hell for deployment!
and amsn is meant for n00bs mainly, I mean, the majority of our users only know how to single-click and install, so we can't force them on compiling, I know that by experience, I spent countless hours giving support for the users and those are the facts!
now, let's considere another aspect of C++, C++ is not object oriented.. it does have support for pseudo-object-oriented programming, but it's not good enough, Java and C# are object oriented (many others I'm sure, I just don't know them) but C++ has that huge flaw where it tries to stay backward compatible to the C syntax, which makes it very bad. It only gives the illusion for OO... and most people (who know better) hate C++ because of that. We don't want to start working on such a language. Java is good, but graphically, it's the worse, + dependance on a JVM is very bad (Tcl also depends on the interpreter, but it's a 2MB directory and we're done, as opposed to java where the JVM is 18MB and it needs to be installed + reboot...)
Now, like Phil said, we don't have null pointer exceptions, and don't try to play him smart, he knows what he's talking about :p segmentation faults are the same as NPE you try to access memory on a null pointer, you get the segfault, and it's really annoying.. you need to recompile everytime, it's annoying...
if you used amsn svn, you'll easily realize this, every morning you 'svn update' and you're done! no compilation needed, no risk for a segmentation fault, it's just easy!
tcl doesn't have strong type checking and no memory management needed. Developping in Tcl will take you at least 30 or 50 times less time than in C++ because of its whole simplicity. And the performance? unnoticeable!
for example, we paid a guy for 4 months to develop a library in C (object oriented with Glib... I know, I also hate that) and he didn't finish the job after 4 months, we couldn't even connect and authentify...
I just did the whole design, and I wrote in Tcl object oriented (with Snit) a library for msnp11, msnp12, msnp13, msnp14 and msnp15 (not completed) in 3 days, along with the account manager, a data manager, and I even was able to partially integrate it with the current GUI of amsn... 3 days... that's the difference of ease of use/power between Tcl and C++... the reason : you don't need to worry about memory, you don't need to worry about the libraries, about the pointers, about compiling 100 times before it works... with tcl, you modify something, you type a command in a shell and it reloads the latest source, no need to even restart the application! you don't need to write code to test your new code, you launch amsn, open the console and call your new functions directly from the console (Tcl is actually a shell scripting language, so it has a shell where you can write any code you want, on the fly..)
And finally, I work on windows right now, I try, test, it works, I commit.. no need to go on linux and try it out, no need to wait for the mac maintainer to be online to ask him if he can apply my patch, see if it compiles on mac, and test it...
if Tcl code works on one machine then it will work on all other platforms!
so.... the idea is to have a Tcl protocol, a Tcl core, a Tcl data storage (contact list, users, groups, your settings, etc...), and the GUI can be anything! it can be Tk (look at the new contact list, isn't it nice ? so why use gtk if we can do a great contact list like that with Tk) alongside with Tile, and Tkhtml! it can be some other GUI module in some other language, GTK/QT/wxwidget/whatever it can be anything, we don't care...
right now, we don't have any real plans on the GUI part, so it will be decided later, but it would be best if it was only ONE module because otherwise it would be difficult to maintain multiple interfaces everytime there's a little change...
Why instead of writing a new libmsn in C, don't you contribute to Telepathy project and use only that library in version 2 of aMSN?
the lib in C was supposed to be the new connection manager for telepathy, so yes it was to contribute to Telepathy....
but right now, we decided to stop the telepathy solution and go with a smoother tcl solution, internal events, no dbus, etc... makes it a lot easier and will help motivate others who don't like the telepathy solution either.
