aMSN Forums
July 07, 2020, 09:28:16 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: New forum for aMSN !!
 
   Home   Help Search Login Register  
Pages: 1 2 [3] 4 5 ... 9
  Print  
Author Topic: Announcing aMSN2!!!!  (Read 338847 times)
boyska
Newbie

Offline Offline

Posts: 15


View Profile
« Reply #30 on: June 14, 2008, 11:10:46 am »

I like the idea of "joining forces" VERY good, that's the only way to have a great msn client.
But I have some technical questions ( I'm not an expert, but I can code in python and I'm developing a litlle plugin):
1. we'll have different guis, that's very good, but... how about plugins? A lot of plugins use the GUI, even if just to put an icon or something like that. How will aMsn2 (please change this name  Tongue ) handle this? If I use the gtk gui, can I use a EFL plugin? (of course this will not integrate perfectly, and of course this will require a lot of library and so on... but sometimes we *want* a plug-in, and I don't want to choose the interface just because it is the only one that has that plugin) Or are you planning to have an "abstract UI interface", so that for example adding an item to the toolbar will be something like "aMsn2UI.toolbar.add_item(...)".
I would prefer the second way, obviously, but this will require much more work to GUI developers.

2. will aMsn allow different protocol implementations ( yes, i'm talking about emesenelib Cheesy ) ? I think that this will be very important because in this way emesene could easyly be ported to a "flavour" of aMsn2 (just choose emesenelib and emesenegui ;-) ). I'm not a fanboy, I just think that this will save a lot of devs!

My compliments for the idea, I'll try to do something useful for this great project
Logged
billiob
Administrator
Super Power User
*****
Offline Offline

Posts: 1350


View Profile
« Reply #31 on: June 14, 2008, 11:16:14 am »

We use the forum as a bug tracker...
Logged
boyska
Newbie

Offline Offline

Posts: 15


View Profile
« Reply #32 on: June 14, 2008, 11:25:46 am »

I think that this is not the right place to talk about it, so I propose a new topic to talk about the name (should we change it or keep it?). This thread will soon become confusing and I think that there's still a bit of confusion (or at least some aspects are not clear to me... i'll watch the code as soon as possible)
Logged
pacho
Newbie

Offline Offline

Posts: 3


View Profile WWW
« Reply #33 on: June 14, 2008, 12:40:49 pm »

Quote from: "billiob"
We use the forum as a bug tracker...


OK, thanks for information :-)
Logged
kakaroto
Administrator
Super Power User
*****
Offline Offline

Posts: 9425


View Profile WWW
« Reply #34 on: June 14, 2008, 03:24:57 pm »

Hi again,
@boyska, you're right, this isn't the place to talk about bugtracking, etc... and also, we're still in the start of the project, so we're far from those details.
About plugins, if the design is done correctly, aMSN should work the same with any front end, so a plugin that adds a feature should work the same with all front ends... but I think we could have a plugin setting (like description, author, etc..) that states what front ends it's compatible with.. so if the plugin is front end specific, then it can be set to be used only with that front end. Anyways, all those are implementation details.
I just want to remind you that aMSN2 is a code name, the application will still be called aMSN... it would just be aMSN version 2.x...
About protocol implementations, like I said before, we'll only use one protocol library, that's far enough as we don't need to implement/maintain two protocol libs.. also read my previous posts for explaining why we want to do it this way and why multi protocol is a bad idea!
Logged

KaKaRoTo
profoX
Newbie

Offline Offline

Posts: 8


View Profile WWW
« Reply #35 on: June 14, 2008, 08:04:50 pm »

I've done some work on the Qt 4 front-end today Cheesy

Check this screencast to view my work so far:
http://85.17.105.113/~wesley/files/amsn_qt4_preview1.ogg

Or have some screenshots, but then you won't see my sweet fade effect :cry:
or the slide effect in the temporarily very ugly contact list :roll:

This is just a test style! If you think it's ugly, don't worry, because by default it will use your system theme
(on Windows, Mac OS X, KDE and GNOME [only from Qt 4.5 or with a backported QGtkStyle])
It will also become themable a bit by using Qt StyleSheets.



Comments are welcome. I prefer positive ones. Cheesy but negative ones are fine too.
Logged

Human Knowledge Belongs to the World - AntiTrust [2001]
Moredhas
Newbie

Offline Offline

Posts: 5


View Profile
« Reply #36 on: June 14, 2008, 10:11:51 pm »

profoX's Qt theme looks very neat, both in the "Wow!  That's neat!" sense, and the tidy sense Smiley
Logged
lucianolev
Power user
*
Offline Offline

Posts: 56


View Profile
« Reply #37 on: June 15, 2008, 01:53:00 am »

Hi! I've been following both forums threads and I could not resist to give my opinion.

1. Regarding the name change, I think that coming up with a good name (btw, i like eMSN!) and new fresh website would be great. aMSN2, as stated here, will be not only a COMPLETE rewrite in another language, but also new people working on it. I know that aMSN has gain popularity and it's important as a brand but I think that if marketing stuff is managed correctly, aMSN will not decrease its user base but on the contrary, new adopters will come. As an example, look to Pidgin, it's name change was positive in every aspect (i think).
Also, just imagine a free software messenger client with latest protocol support and multi GUI support, it will be impossible to be ignored! It will be, by far, the most used messenger client at least in GNU/Linux and MacOSX, and it can even rival the official client in Windows! So kararoto, please reconsider this idea, no matter what's the name, if you manage to build a client with the characteristics said before, you got no competition.
Finally, take into account that those how didn't like aMSN for its look & feel, it will be difficult to transmit them that now aMSN does not look the same as before; just think of non-tech people, who don't know what's gtk, python or qt.

2. About the client goals and design in general, I think the most reasonable idea is to concentrate in only one protocol implementation and put all the efforts there. I understand that many people could prefer some toolkit from another but does it really make sense to work on multiple implementations? :shock: IMHO, it's just duplication of work. So please, current emesene and aMSN developers, and everyone who is thinking in creating an live messenger client, work together on improving pymsn! Cheesy
So, in my opinion the design should be:
Protocol Lib (like an improved pymsn) -> Core & GUI abstraction classes -> Frontends
Also, you should keep the idea of keeping it simple, Live Messenger-like interface and NOT multiprotocol. IMHO, emesene has accomplished this quite right.

So, what do you think?  Smiley
Logged
kakaroto
Administrator
Super Power User
*****
Offline Offline

Posts: 9425


View Profile WWW
« Reply #38 on: June 15, 2008, 02:36:58 am »

Hi,
again, I disagree about the name change, I don't want to talk more about this since I already said everything I wanted to say on the subject. If other aMSN developers start to think it should be done, then I might reconsider, but as far as I know, all aMSN developers want to keep the same name (it was already discussed in a thread on the mailing list a long time ago).
About the goals, I agree and that's what was planned from the start.. single protocol,multiple front ends, improve the protocol lib (whatever we need for aMSN, we'll implement it in pymsn, so don't worry about "pymsn lacks X or Y").
There won't be much code duplication, the design is so that the front ends will do the minimum and everything will be in the core.
Logged

KaKaRoTo
profoX
Newbie

Offline Offline

Posts: 8


View Profile WWW
« Reply #39 on: June 15, 2008, 02:41:00 am »

Quote from: "lucianolev"
Hi! I've been following both forums threads and I could not resist to give my opinion.

Hi lucianolev! I am a very new developer myself (working on the Qt4 frontend) so my answers might not be 100% accurate, but I'll give it a shot anyway.

Quote from: "lucianolev"
1. Regarding the name change, I think that coming up with a good name (btw, i like eMSN!) and new fresh website would be great. aMSN2, as stated here, will be not only a COMPLETE rewrite in another language, but also new people working on it. I know that aMSN has gain popularity and it's important as a brand but I think that if marketing stuff is managed correctly, aMSN will not decrease its user base but on the contrary, new adopters will come. As an example, look to Pidgin, it's name change was positive in every aspect (i think).
Also, just imagine a free software messenger client with latest protocol support and multi GUI support, it will be impossible to be ignored! It will be, by far, the most used messenger client at least in GNU/Linux and MacOSX, and it can even rival the official client in Windows! So kararoto, please reconsider this idea, no matter what's the name, if you manage to build a client with the characteristics said before, you got no competition.
Finally, take into account that those how didn't like aMSN for its look & feel, it will be difficult to transmit them that now aMSN does not look the same as before; just think of non-tech people, who don't know what's gtk, python or qt.

I personally don't really care about a name change. It has both positive and negative effects. What I care about is the actual code. The fact that aMSN 2 is a complete rewrite should not mean that the name has to be changed. Either way I am fine with it. The main aMSN developers have already stated their reasons for wanting to keep the aMSN name. If you think those reasons are invalid, be prepared for a lengthy discussion with them. But in the end, does it really matter so much? ...maybe we should make a poll...

Quote from: "lucianolev"
2. About the client goals and design in general, I think the most reasonable idea is to concentrate in only one protocol implementation and put all the efforts there. I understand that many people could prefer some toolkit from another but does it really make sense to work on multiple implementations? :shock: IMHO, it's just duplication of work. So please, current emesene and aMSN developers, and everyone who is thinking in creating an live messenger client, work together on improving pymsn! Cheesy
So, in my opinion the design should be:
Protocol Lib (like an improved pymsn) -> Core & GUI abstraction classes -> Frontends
Also, you should keep the idea of keeping it simple, Live Messenger-like interface and NOT multiprotocol. IMHO, emesene has accomplished this quite right.

As far as I am aware, those are _exactly_ the plans. KaKaRoTo has already stated that eventhough aMSN 2 is going to be very modular, the main developers will only work on making it the best MSN client ever, because their reasoning is that it's better to have a client that implements one protocol (the MSN protocol) perfectly, than it is to have a client that implements many protocols, but not one protocol works like it should, because there are too much protocols to work on.

We also have some teams internally. The core aMSN developers are working on improving pymsn and on the aMSN core, and we have different teams for the front-ends, so everyone can focus on their speciality. The current front-ends already get their data from the core and from a GUI abstraction class.

edit: oops, KaKaRoTo is faster than me in responding to your message :roll:
Logged

Human Knowledge Belongs to the World - AntiTrust [2001]
lucianolev
Power user
*
Offline Offline

Posts: 56


View Profile
« Reply #40 on: June 15, 2008, 03:24:58 am »

@profoX and kakaroto:

Well, regarding the name change, i was just pointing out why i think the name change is the way to go. The only downside that I found about changing the name it's the effort and time to do this, which I respect. Also, I fully agree that the code it's far more important. However, a poll could also be a good idea.

As regards the design, no complains.   Cheesy  My doubt was primary because of some posts in emesene forum (http://emesene.org/smf/index.php/topic,1248.30.html) which implies that there will be multiple backends, pymsn and emesenelib :shock: I really think that be should minimize abstraction layers when it makes sense...
Logged
kakaroto
Administrator
Super Power User
*****
Offline Offline

Posts: 9425


View Profile WWW
« Reply #41 on: June 15, 2008, 07:15:33 am »

yeah, there's no need for two backends.. I think the emesene guys are just dreaming about emesenelib not dying and being used somewhere :p seriously though, the design will make it possible to change backends, but it's only so we can have a good layered system, it's just the design, not the purpose...
problem is that the amsn2 design was made taking into account a lot of experience trying to maintain aMSN... development of aMSN slowed down a lot lately because it was badly designed and maintaining the code required a lot of work (== amsn's code is crap). The biggest challenge we had was that the GUI was doing protocol stuff and protocol functions were calling the GUI functions... it was a mess.... we did a lot of refactoring, a HUGE amount, it's much better now, but it's still crap and GUI and protocol are still mixed, so it's a bit hard...
When we decided that we should do amsn2 (back in 2006 I think.. or even earlier), we said that one important thing was to have layers, and have events used to talk between gui and protocol... and that's what we're doing here...
Logged

KaKaRoTo
olskar
Newbie

Offline Offline

Posts: 7


View Profile
« Reply #42 on: June 15, 2008, 11:34:39 pm »

I am not really sure what this new version brings but "It will not be in tcl/tk" is enough for me to love you Cheesy
Logged
Auria
Power user
*
Offline Offline

Posts: 121


View Profile
« Reply #43 on: June 16, 2008, 12:54:06 am »

Great news, good job!
Dropping tcl/tk was IMO the best decision possible.

Looking forward to see more of it
Logged
boyska
Newbie

Offline Offline

Posts: 15


View Profile
« Reply #44 on: June 16, 2008, 02:50:58 pm »

I see that the name will never be changed (and they have their reason to do so...);
anyway some of the "change" ideas are good: so why don't we try to take the best of two worlds?
What I'm proposing is a new "codename" or "subtitle" or "motto", like for example "Amarok - rediscover your music".

Doing something like "aMsn2 - AMaSiNg" (ok, that sucks, just to explain) will, at one time, underline that this IS aMsn and that this is something NEW.
But this is just marketing stuff, and there's no hurry. Long life to aMsn!

What do you think about it?
Logged
Pages: 1 2 [3] 4 5 ... 9
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!