Announcing aMSN2!!!!

[profoX]

Don't worry. You are free to use which front-end you want.
A Gtk+ and Qt 4 front-end are in the making already.
It's not because the main aMSN developers loves some special toolkit that you will have to use it.
The Gtk+ and Qt 4 front-ends will probably always find maintainers so it will stay maintained as well.

[kakaroto]

Thanks all for the comments!!
I'm also happy to see a lot of QT people here... I always saw the GTK folks yelling and requesting a GTK front end, but never the QT guys...and the QT front end is looking so nice now!!

EFL is a very, very bad idea, and your justification for using it does not hold water. You say:

GTK did not fit the requirement of being able to have a background image on a text widget (unless doing a lot of hacking and reimplementing the text widget)...

Which is the reason that supposedly leads you to EFL. Then you say:

For those who do not know what it is, the EFL is the Enlightenement Foundation Libraries. It's a set of libraries that makes building UIs such a beauty! It only has one.. euhh.. two... humm.. a few problems :
...
3 - we cannot embed an image inside a text widget.. so no smileys support...

Hey! It seems that EFL has exactly the same problem as GTK!

@Lobotomik : This is why we kept amsn2 a secret for so long, because I don't want to hear trolls flaming... and this is also why the main point here in amsn2 is that it's multi-front-end!!! I thought this would finally please everyone, but it seems when someone just wants to troll, he'll find a way to troll anyway!
Go read the post completely, do not stop at the first sentence that talks about EFL... take a look at the screencast and rethink about what you said...
First, the GTK limitation is not the same as EFL at all, GTK doesn't allow a text widget (chat window) to have a background image (only plain white/red/whatever color background).. while EFL allows this very easily but you can't embed an image inside a text widget, like for inserting a smiley in the middle of the text.

* Hardly anybody knows, or remotely cares about, EFL.

wrong, a lot of people know and do care about EFL, if you don't know or care about it, it doesn't mean everybody is like you!

* An EFL application will look martian in any popular desktop. Just look at how nice Emesene looks in Gnome, compared with the clunky feeling of the (more powerful) aMSN.

so ? a QT app might look alien in KDE or a GTK app would look alien in Gnome, and in my case, where I use E17, both QT and GTK would look alien... anyways, aMSN never looked 'integrated'... if you use gnome, you can just use the GTK front end, if you have KDE, then use the QT front end, if you want something different, something that looks like more like WLM, then use EFL, the choice is yours!

* There's very nice things in GTK and Qt like gstreamer, phonon, cairo, arthur, clutter etc. which you will probably miss.

EFL also has a gstreamer element and we can use cairo or clutter or opengl or whatever for rendering our window with no effort whatsoever...
you should read up before stating wrong stuff

* The world is moving to smaller computing formats: MIDS, netbooks, cellphones. Your choice of EFL would force the porting and addition of a rather sizeable library to anybody interested on running aMSN2.

again, read up before stating wrong stuff.. The InDT Nokia Research department is using the EFL extensively, EFL works and is so fast on the Nokia internet tablets, it also works well on openmoko and there never was any need for porting it.. just compile and run... there is a huge set of libraries but it's modularity, they are all small...


About using webkit for gtk, yeah, but unless you draw the whole window, it's useless...  my idea was to use webkit only for the output text widget...

Reimplementing in Python is a good idea, which brings you the opportunity to kick an aging, clunky language into the trashcan, and finally let aMSN blend in nicely with the desktop. But that is not what you will achieve with your choice of toolkit. With EFL, I predict slow progress and an ugly, clunky app. I hope Emesene developers carry on with their work in producing an excellent MSN client and add the missing bits soon, because I believe that is the way to go. Why they should drop their goal and jump into this project that has nothing done yet, but is already painting itself into a corner, I just cannot fathom.

You're just rambling! Again, read my post! WE didn't choose any toolkit, YOU choose the toolkit you want!
And you have no reason to 'predict' slow progress with EFL.. and uglyness? clunky? did you see the screencast ? seriously! I don't think that looked ugly.. or maybe it was, but it was the skin I made, not because of EFL...
and did you notice when I kept expanding/collapsing the groups in the contact list? doing it as fast as I can will collapse/expand the groups, with all the animations and my CPU will be used to a maximum of 2%... no toolkit can beat that! oh, and it was software rendering, not even using hardware acceleration for doing that.. which I could have if I wanted to!
If you want emesene to be worked on, then you're missing the whole point, if they decided to join us is because they think amsn2 is the way to go, it's a project that will supercede anything currently existing!
Again, I think you're just an emesene/gnome fanboy who didn't even finish reading my post and decided to start trolling...

[Fenix-TX]

I'm very amazing with the screencasts! EFL sounds and looks very nice. And it's nice to see differents GUI for an application, that's rocks!

And welcome new developers!! aMSN is growing and growing more!! Thanks to all devs and aMSN team!

[Fabioamd87]

ahhh finally someting goes from the good side.
I'm using emesene from many months because of the slow of amsn client...
I dont know the reason but i think is the tlc/tk on my ubuntu system.
another reason of my choise is that emesene is growing very fast

have 2 different project implementing the wheel on every fu***ng feature is really BAD
I will choose aMsn + gtk (python + gtk is the best choise on my ubuntu system)
BUT I need an importer for emesene log, otherwise i must still continue to use emesene

sorry for my bad english skill


ps: amsn and emesene have a really good developers, i think amsn2 can be very good!

[mattmill30]

Hi, is the amsn2 development project available for alpha distribution?

If so, which front end would you recommend for which OS, e.g. which of the technologies is readily available for Linux, Windows, Mac, etc.

And finally, where can the packages be downloaded from? are they in source and if so which compilers/dev libraries do we need to compile it for our native OS's.

Thanks.

PS: if this has already been written into a guide, my apologies, please can you post a link to the relative guide, thanks.

[kakaroto]

Hi mattmill30,
amsn2 source code is available in SVN (http://amsn-project.net/wiki/SVN replace the last 'amsn' with 'amsn2' in the SVN URL).
The front ends are for now :
efl for linux, cocoa for mac, qt4 for windows... we also have gtk if you want (./amsn2.py -f gtk)
there are no packages, just source code.. it's python so you don't need to compile anything...
aMSN2 is still in its first days, so it's not yet stable or complete, you can't use it to chat yet, you can only connect and look at your contact list...
If you want to test the EFL front end, there's a README file in there...

[dx]

Our expert IRC trolls and forum users are telling that amsn2 is not a good name, because they already think that everything with "amsn" in the name is "ugly". I am not suggesting you to use "emesene", nor to leave "amsn". At least change the meaning of that A (who is that "alvaro"?)

EFL is a very, very bad idea,

Since you have trolled kakaroto unintentionally, this is my point of view: EFL is just one of the selectable frontends. Call it obscure, alien, whatever. But from a developer point of view, EFL is exciting, fun to code, and clearly the future. Also, it's the most flexible alternative available. It seems that the amsn team likes to design the GUI freely, regardless of users saying it's ugly because it lacks antialiasing. edit: Of course this new toolkit renders fonts properly, with antialiasing and everything. I meant that tk is ugly because before version 8.5, etc.

Why they should drop their goal and jump into this project that has nothing done yet, but is already painting itself into a corner, I just cannot fathom.

You've got an interesting point there. Just to clarify, we won't drop emesene. That's all I can say now for sure.

BUT I need an importer for emesene log, otherwise i must still continue to use emesene

That's easy, we can even use the same database file directly. But there's nothing chat-related done right now, afaik.

[Spartan]

kakaroto you don't need to feed the trolls.
The people who knows and used EFL, knows how powerfull and fast it is!
I think that an EFL front end it's a GREAT decision, in my humble opinion, it's one of the best graphical toolkits around. And it's a great opportunity to show to the world what it's capable of. (I love e17 )

[Moredhas]

I suggested this in this thread's partner on the emesene forums, and a couple of people liked it.  I thought I might suggest it here too, and explain my reasoning.

I think a good name, instead of calling it "aMSN2", would be eMSN.  aMSN came from ccMSN (according to Wikipedia), so it's name kind of inherited from that, and this version sort of comes from emesene.  More of a merging of the projects, really.  eMSN could sound like emesene if you treat the e as a sound and not a letter, and it shows the heritage of aMSN, in the way it's typed.

Just a suggestion, take it or leave it  

[kakaroto]

Hi,
thanks dx for your clarifications
@Spartan : yeah, I know I shouldn't feed the troll.. but I have a really bad temper :p and I didn't want that guy to be misleading whoever comes here and reads his post and sees no explanation to what he claimed...
glad to see a fellow e17 lover
@Moredhas : hi and welcome to our forums...
ok, I see where this is going, I'd like to note to you and to dx, that this isn't "amsn2", this is actually "amsn", the "amsn2" is just a codename so when we talk about it, we know if we talk about the tcl/tk or the python one... it's a simply a rewrite of aMSN. It will still be released as 'amsn' but the version will be 2.x (as opposed to our 0.x versioning of now).
I don't think a name change should occur, we love amsn's name, everyone knows amsn, and the name holds its reputation, it's like a brand.... about the name  "alvaro" that dx mentionned, alvaro is the original guy who started the project, he took ccmsn, made his changes, couldn't contact the original author, so he had to fork and he named it "alvaro's messenger" after his name, thinking noone would use it anyway... but a long time ago (2 years maybe?) he said that this project is not his own anymore because of all the contribution the project received from several people and that he does not feel that it's justified to keep the client named "alvaro's messenger", so we changed the name to an unknown name.. "another messenger" or "awesome messenger", whatever you want to put there for the meaning of the letters.. but it actually just became "amsn" with no real meaning behind it...
someone from your IRC channel reported that the website's title says "alvaro's messenger", that's probably a mistake that noone ever noticed... we'll get it changed!

Anyways, about changing the name, I really don't think that it should be changed, I fully understand your motivations, you guys are emesene fans and you don't want emesene to die, or its name to be forgotten, etc... but this project is not emesene, the core stays aMSN, the aMSN team will build it, we'll make it the way we think it should be, it's our code, our design, our ideas, it's our way of dealing with the users, etc.. it all stays the same! the emesene team are the gtk maintainers, and as you know, gtk is one front end amongst others... if we had to change the name to accomodate other developers, we would end up with a project name like 'kepyeMSN" (k for KDE.. the qt front end developed by a kde developer... 'e' is for the efl.. py for pymsn that does all the protocol, eMSN for your idea of merging emesene and aMSN...) or worse....
Like I told someone earlier, the front end developers can make the about box the way they want, we'll feed the front end with a text for the about box, and they can have two frames, one with the amsn's about message, and another like "This front end was developed and brought to you by the emesene team" or whatever...
I think it's just a waste of time trying to change the name to accomodate everyone... I prefer to think of the emesene guys (or others) that join us, simply as "they joined us".. they are part of our team, they joined the big aMSN family, they joined the aMSN community that's been there for 6 or 7 years now I think... rather than seeing this as "those guys are amsn, and those others are the emesene guys".
I don't know what you think about this, but that's my opinion...

and.. I don't want to be harsh or anything or force anything on anyone, but a simple fact...  aMSN has got as of today 19,637,688 official downloads (http://sourceforge.net/top/topalltime.php?type=downloads) without counting those who download it through their distribution's repositories and those who downloaded it from our third party ftp servers and bittorrent (when we crashed sourceforge after the 0.95 release of aMSN that got slashdotted)... if we join with a project as big as aMSN in terms of userbase/community/etc.. then we could rediscuss the name change.
The whole idea, design, work comes from us.. the emesene team and others decided to join us for our work, it's not us who decided to contribute to emesene... (I've helped dx and others a lot with my knowledge of the protocol for example.. I never said they should put my name in the about box or give me credit for it or anything...)
as an example..
If microsoft were to merge with the developers of a small, new (though fast growing) company... or rather, if the developers of that company were to join microsoft because it offered them something better or that they were interested in.. I don't think they would ask microsoft to change its name...
if microsoft and apple were to merge.. that's another story...
That's just the way I see it, and I know it may sound harsh or unrespectful to some of you, I do not want to irritate anyone, just stating some facts, and I hope the message gets through without hurting anyone's feelings.
oh and by the way, although the emesene guys are the gtk maintainers, I see them as more than that, I see them as part of the aMSN family now and of course their ideas will be taking into consideration just as much as any other developer from the team. They will contribute to the core or protocol if they want to, there's nothing stopping them from doing so. So I hope you don't take my words as "they are just the gtk maintainers and they mean nothing more to us"...
Thanks for reading and sorry about the huge post (again:p)

p.s.: the emesene forum post Moredhas talked about is linked here : http://emesene.org/smf/index.php?PHPSESSID=on09iek2a4skoqmoo94tim3iq6&topic=1248.0

[Moredhas]

This might be a stupid question, since I don't know much about how aMSN works on the inside, but since you can drop in another protocol library (like using emesenelib instead of pymsn), would it be possible to use libpurple, from Pidgin, and have aMSN access Yahoo, AIM, and the others Pidgin supports?  I probably wouldn't want to, since I haven't used Yahoo for years, but a lot of people use Pidgin because it's multi-protocol.

[kakaroto]

Hi,
such a short answer to such a short post.. lol
Anyways, your question is not stupid.. but if you search a bit the forum and maybe the amsn-devel mailing list too... you'll see that we have previously discussed this type of thing and the general idea is "do not go multi protocol".. I won't repeat my reasons here because it's late and I'm tired of typing.. but just read this thread instead : http://www.amsn-project.net/forums/viewtopic.php?t=4512
about the 'another protocol library', I think one library is enough, as explained in the other thread, the idea is to have the layers separated, a good design, but without the intention of using this ability that we gain by being well structured. We go with pymsn because it's pretty good, pretty complete, and very well designed.

[panda84]

I'm also happy to see a lot of QT people here... I always saw the GTK folks yelling and requesting a GTK front end, but never the QT guys...and the QT front end is looking so nice now!!

Maybe KMess (http://www.kmess.org/) did a good job to fulfill Qt / KDE users expectations, so there hasn't been a lot of people asking for a Qt front-end so far. Did you get in touch also with them to cooperate where it is possible?

Just another little question... Is aMSN 0.98 going to be released or will it be dropped to concentrate on aMSN 2 development?

Regards,
Diego

[billiob]

Since amsn2 is far from being released, we'll release amsn0.98 before.

[pacho]

aMSN currently uses sourceforge bug tracker http://sourceforge.net/tracker/?func=add&group_id=54091&atid=472655 , I would suggest use other bugtracker like launchpad.net for example. I find it easier to use, for example, searches are usually easier (at least for me) and I think that it has more order.

Thanks a lot